Re: A structured format for dates?

On Thu, Jun 16, 2022 at 10:27:58AM -0700, Austin William Wright wrote:
> > 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]

In fact all depends whether these dates are intended to be consumed by
humans or machines. Leap seconds were only invented to keep the human
calendar aligned with the stellar one. Computers don't care. And humans
don't care either as long as dates are in fact used to transport a form
of duration. If you need to indicate when a document is supposed to
expire because you added a timeout to the current human date, the expiration
date cannot care less about the leap second than the original date, what
matters is only the duration, which again is just a number of seconds.

There may be situations where human dates are important, e.g. opening an
online vote or the sales for a much sought product where some frustrated
losers could argue that the date was not respected. But I'm not seeing
such dates used for decision making transported in HTTP headers, for the
main reason that the one writing the date cannot know when the consumer
will receive it, thus it's inaccurate by design.

So I tend to think that most of the dates transported in headers, if not
the entirety, are targetted at computers and as such, are essentially
relevant to calculate durations or ages. And there, integers will be
correct by design.

> > 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.

I'm pretty much convinced that as most of the times when there is a long-
lasting disagreement on a design choice, it's because we try to make it
fit different needs. Typically using a date for both durations and human
dates is wrong and cannot satisfy both incompatible needs when accuracy
enters the list of requirements. Even the GPS time that many consider the
most accurate have no care for human time and it's very possible that the
date displayed in your car is off by the sum of all the leap seconds
accumulated since the car was designed and the time offset hard-coded
there! Thus it's possible to have microsecond accurate clocks with integral
numbers of seconds variations. And most of the time even humans don't care.

Cheers,
Willy

Received on Friday, 17 June 2022 07:39:00 UTC