On Mon, Jan 27, 2020 at 8:17 AM Steve Summit <[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 > > , 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? Warner
_______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
