Re: date without time

[Alejandro Colomar]

Hi Bruno,

On Fri, Aug 02, 2024 at 10:42:03AM GMT, Bruno Haible wrote:
> Alejandro Colomar wrote:
> > However, I'd say that's more likely to be that the authors of RFC 9557
> > didn't think of dates without time (maybe they didn't think of a case
> > where this would be useful), rather than having expressely desired to
> > not include it in their standard.  And so, let's say this is a tasteful
> > extension to RFC 9557.  :)
> 
> Dates without times open another can of worms.
> 
> It starts with the question "What is a day?".

A day is a period of around 24 hours.  (That "around" covers the fact
that there are the SI day, the stellar day, the sideral day, and
whatnot.)

A day-precission timestamp is a timestamp at any point of that day.
(In fact, in /etc/shadow they are stored as full days after Epoch, not
 as a number of seconds, so it is really a day-precission timestamp.)

Similarly, a second does not have a clear definition.  There's the SI
second, which (according to Wikipedia) was historically defined as
1/86400 of a day, and now has a more perturbing definition, in terms of
the Cesium 133 atom.  Then, there are atomic seconds, which are "voted"
instead of having a standard definition.  And also whatnot, of course.
UT1?

A second-precission timestamp is a timestamp at any point of that
second.

> If a programmer answers it with "A day is a 24-hours period", they already
> lost, because there will be bugs across the entire DST period of the year.

Second-precission timestamps have similar problems due to leap seconds.
Of course, since leap seconds are smaller than leap hours or days, we're
less concerned about them, except for the pedantic TZ maintainers that
need be concerned about them.  Or maybe nanosecond hackers and banks,
such as in movies.  But not the average person.  But the problem is
still there.  :)

> A more intelligent programmer will answer it with "A day is a period of
> 23 or 24 or 25 hours, going from 00:00 to 24:00 of each date", and represent
> it through the 00:00 time point of the date. This programmer nearly has it
> right. But when they compute, say, <day> 08:00 = <date> + 8 hours, they are
> lost as well, because there will be bugs on the days where DST starts or ends.
> 
> An adequate answer is a period of 23/24/25 hours, represented through the 
> 12:00
> time point of the date. For business purposes (say, work hours from 08:00 to
> 17:00), the time points get computed correctly. However, care must be taken
> in various conversion functions, that the 11/12/13 hours offset gets taken
> into account.

The 12:00 time point will still be problematic in time zones near the
time-zone wrap, I suspect.

> The best answer is probably an interval with two time points (<day> 00:00 and
> <day+1> 00:00). But programmers dislike that computations take twice as much
> time as "necessary".
> 
> In summary, I think dates without times were wisely excluded from RFC 9557.
> 
> Bruno

Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es/>

signature.asc
Description: PGP signature