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

[Taylor R Campbell <campbell+netbsd-source-changes-d%mumble.net@localhost>]

> Date: Sun, 23 Oct 2022 12:19:37 -0600
> From: Warner Losh <imp%bsdimp.com@localhost>
> 
>                                      You must have a table of all past
> leap seconds to do any kind of sensible mapping. And you also must
> have some way to keep that up to date, [...]

It's the same for all civil calendar matters with political changes
around summer time, but at a smaller scale: with an outdated tzdb,
where localtime might be off for an hour, mktime might be off by a few
seconds.

> > And, of course, at subsecond resolution, the POSIX clock rewinds.  The
> > monotonic clock correctly has t1 < t2, but POSIX(t1) > POSIX(t2).  And
> > this erratic behaviour is much worse than a typical NTP-driven clock
> > adjustment at random times, because by design this erratic behaviour
> > happens on ~every computer on the planet simultaneously!
> 
> Yea, if NTP knows about the leap, it can deal with it. The problem as you
> say comes in when the stratum 1 servers don't announce the leap second
> far enough in advance for the implementations to cope. It then devolves to
> the 'when, exactly, do you step the time back' problem since there's a
> couple
> of choices, unless you have the 'leap smear' ntp servers which do it over
> a few hours.

I mentioned NTP-driven clock adjustments as an example of _other_
times that a POSIX clock might rewind.  Such adjustments arise from
local clock drift and so occur randomly, in contrast to the rewinding
on leap seconds that is globally coordinated as a deliberate design
decision of POSIX leading to simultaneous worldwide computer system
failures.

NTP doesn't have to know about leap seconds at all, nor does POSIX.
They could both just report the number of SI seconds (averaged in the
usual TAI way) since an appropriate epoch, and all the leap second
adjustment logic could be ripped out and moved to tzdb and mktime just
like time zones and summer time.

The fundamental problem with a POSIX clock -- and to a lesser extent
NTP, although NTP at least transmits additional information to work
around it during a leap second transition unlike POSIX programs -- is
that it goes out of its way to step back the _internal concept of
timecounting_ (tick-tick-tick, counting what everyone expects to be SI
seconds) just to deal with an _external civil calendar presentation_,
like the summer time change.  And it makes sure to do so
simultaneously on all computers worldwide.  That's a spectacularly bad
design leading to tremendously costly mistakes.  Leap seconds aren't a
big deal; the erratic design of POSIX clocks is.