Richard Thomas wrote: > On Sep 27, 2016, at 7:41 PM, Steve Summit <[email protected]> wrote: > > It just feels right to me that any shenanigans should be confined > > to the day that the leap second is at the end of, and that on the > > next day, everything is back to normal. > > Remember that the leap second occurs at midnight UTC, not midnight your local > timezone.
Indeed. > Does this change anything? If a leap second manifests as an awkward 1s jump in Posix time, it could matter a lot. But if we're smearing the leap so that it's invisible to all but the most discerning of clients, I don't believe it matters when it happens. > > An alternative is to do the smearing purely mathematically, > > between (2) and (3), notionally as times are being handed to > > user mode by gettimeofday() and the like. I don't believe it's > > necessary to tinker with internal clock steps or frequencies. > > This is far and away the easiest solution. > It only involves code changes in one place. > And we already have a good idea of what the code should look like, > because we have the 'right' timezone family that converts between > UTC and TAI. I'd say that's different, though, because the 'right' code *does* make leap seconds explicitly visible; it does *not* smear them away. > In fact, I'd go even further and suggest that the standard should require > that (1) and (2) should be TAI, not UTC. Hoo, boy. Me, I'd say that's a *whole* different kettle of fish. _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
