Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/lib/libc/time





On Sat, Oct 22, 2022 at 10:55 PM Robert Elz <kre%munnari.oz.au@localhost> wrote:
    Date:        Sat, 22 Oct 2022 20:17:57 -0600
    From:        Warner Losh <imp%bsdimp.com@localhost>
    Message-ID:  <CANCZdfqhkZ0XS7LF6LMJvEONtC5DGSoNOnS_UG6fzSf30oGiiw%mail.gmail.com@localhost>


  | On the other hand, adding a caveat that leap seconds don't exist in a POSIX
  | time_t and that's necessarily reflected in the normalization wouldn't be
  | bad.

The problem with doing that is that while we don't install it this
way, it is possible to install tzdata such that leap seconds do occur
(despite that not being posix) either unconditionally, or installing
both and leaving it up to the user by their choice of timezone to use
(which makes rather a mess).

That's true. In the default "UTC system time" clock, leap seconds simply
do no work at all. With the tzdata with leap seconds, they work for a limited
subset of things, but not quite everything because you can't completely
close the gap due to time_t not having an encoding for them. Having tried
to deploy systems that needed to present a pedantically-correct UTC
time to the outside world shows many hole (most of which self correct
and are mostly right not near leap seconds).

I guess a more accurate way of saying this is that leap seconds simply
aren't reliable, cannot be made reliable, and this affects normalization
in ways too numerous to mention due to the details of the tz files, bugs
in the system, and lack of others to implement them correctly.
 
The code works with either set of tzdata files, POSIX stretchy secs,
or UTC with leap secs - claiming that one doesn't happen, or cannot
happen, isn't really correct.

Yea, and even 'posix stretchy sec' is really a misnomer. POSIX simply
counts time without leap seconds. Each second is the same length,
and it doesn't make them longer or shorter. It just assumes some
ad-hoc, beyond the standard method for synchronization. The quality
of these ad-hoc methods ranges from terrible to halfway-decent, but
none are perfect.

OK. I've got my annual leap seconds rant out of the way. Even 15 years
after shipping these systems, the almost (but not completely) right nature
of how computers implement them still has my knee jerking just a little
too much...

Warner


Home | Main Index | Thread Index | Old Index