On 2020-01-27 7:38 AM, Warner Losh wrote:
On Mon, Jan 27, 2020 at 8:17 AM Steve Summit <[email protected] <mailto:scs%[email protected]>> wrote:Hal Murray wrote: > Does anybody know of a good writeup of how to fix POSIX to know about > leap seconds and/or why POSIX hasn't done anything about it yet? I don't know why POSIX hasn't done anything, other than that (1) it's an excruciatingly hard problem, made even harder by (2) the ubiquity and the specific POSIX definition of time_t. > I assume the basic idea would be something like switch the kernel > to use TAI rather than UTC But that seems to end up being a non-starter, because (1) distributing updated TAI-UTC tables is really hard (and basically impossible for certain classes of embedded and/or isolated systems), and (2) everyone knows how to initialize a system clock to UTC at bootup, but almost no one knows how to do so for TAI. The other basic idea is to implement new, proper-UTC-capable kernel mechanisms and interfaces alongside the time_t ones. I'm still a big fan of the clock_gettime(CLOCK_UTC) approach described by e.g. Markus Kuhn at https://www.cl.cam.ac.uk/~mgk25/posix-clocks.html <https://www.cl.cam.ac.uk/%7Emgk25/posix-clocks.html> , but it never seems to have caught on. I went through the exercise of implementing it myself in a homebrew Linux kernel, which I used to post a message to this list a few years back with an honest-to-goodness timestamp of Date: Sat, 31 Dec 2016 18:59:60 -0500 You've just scratched the surface of the problem.How do I touch a file on Sat, 31 Dec 2016 18:59:60 -0500 and have ls -l report that as its timestamp?Sadly, I've never managed to properly release or publish this work. And that sort of gets back to the first part of the question: Why does there not seem to be much urgency about "solving" this problem? Besides the points I mentioned earlier, I can speculate on a few more: * Leap seconds are rare, and many people don't care. * The leap second drought of 1999-2006 rather nastily coincided with a gradual change in the computing industry from "nobody's clocks are synchronized that well anyway, so a second here or there doesn't matter" to the opposite. (But by the time we realized we had a leapsecond problem, it was sort of too late to fix it.) * These days, it seems everybody who has really thought about it has concluded that leap seconds are impossible or a really bad idea, and is sitting around waiting around for the ITU to abolish them, and maybe implementing leap-smeared NTP servers to tide us over in the meantime. Remarkably, though, *Microsoft* of all people seized the bull by the horns and announced more-or-less proper leapsecond support in Windows a little while back; it might be instructive to study that effort for lessons.I wonder how it deals with the externalities problems, where protocols specify UTC times, but then make it a simple count of seconds (ignoring leaps) since some epoch?
Evolution of Timekeeping in Windows https://techcommunity.microsoft.com/t5/networking-blog/evolution-of-timekeeping-in-windows/ba-p/778020 -Brooks
Warner _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
