Re: A structured format for dates?

[Poul-Henning Kamp <[e-mail]>]

--------
Mark Nottingham writes:

> If dates are their own distinct data type in SF, the underlying data 
> model would still be an integer or decimal, but it would self-identify 
> as a date, so that tooling could identify it as such automatically.

If we did, we would just progress to the next level where the
question becomes:  What about time-intervals like "age", should
they also be so tagged so they can be presented as "45m32s" ?

We did not make SF context-free, you need to know what you are
looking for to parse it correctly, so needing to know that some
sf-decimals are timestamps is totally in character.

(If we settle on sf-decimal to support fractional seconds, the
precense of the period and the magnitude of the integer part will
be a very solid heuristic for opportunistic pretty-printing.)

Of course if almost nobody actually uses fractions, the extra ".0"
is just wasted overhead, 11 bits in HPACK, but even then, a sf-decimal
is still shorter and compresses considerably better than ISO-8601
timestamps would do.

Therefore I prefer sf-decimal, but I can live with sf-integer.

Introducing ISO 8601 as yet another textual timestamp format,
offering no upside over the three already codified textual timestamp
formats, would be not only pointless, it would be a regression, for
instance in terms of HPACK efficiency.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[e-mail]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.