> Date: Sun, 23 Oct 2022 12:19:37 -0600 > From: Warner Losh <i...@bsdimp.com> > > 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.
