Re: A structured format for dates?

> On Jun 15, 2022, at 23:22, Willy Tarreau <w@1wt.eu> wrote:
> 
> The thing is, the effort to present *any* human-readable string is always
> worse than converting an integer (or decimal) to the final representation,
> since it's required to pass through such an integer-based representation
> at one point during the operation anyway.

This isn’t necessarily true. Many representations like RFC3339 compare in ASCII order (given certain constraints like, Z time and fixed length year). If only a comparison is needed, then a string-based representation may be just as good.

> The epoch-based representation also has the benefit that you're not required
> to have to guess a timezone nor to be confused by ":60" resulting from a leap
> second once every few years.

Quick, off the top of your head: What happens to the Unix epoch when it passes through a leap-second? What about a negative leap second? [1]

I figure, if fractional seconds are important, then being able to represent a leap-second is probably of some importance.

> Also, applications that want to rely on text-based dates do not all agree
> on the format. Some would like to see the day-of-week there, others don't
> want ISO8601 because it's less readable by humans etc. Thus I'd rather go
> for integer+fraction only.

But disagreement on a Date format is exactly the problem that is being solved here. It is not obvious to me that (a string representation of) a number ought to be the winner just because there has been disagreement in the past.

Cheers,

Austin Wright.


[1] Unix timestamps do not count leap seconds, so positive/negative leap seconds will repeat/skip a Unix timestamp, unless you’re using a more sophisticated scheme like leap smear. As far as I can tell there’s no standardized behavior, it seems likely that naive implementations could exhibit behavior like: 1483228799.0 (2016 Dec 31) ... 1483228799.9 -//-> 1483228799.0 (discontinuous jump) ... 1483228799.9 ... 1483228800.0 (2017 Jan 01)

Received on Thursday, 16 June 2022 17:28:13 UTC