[LEAPSECS] leap seconds in POSIX

[Brooks Harris]

On 2020-01-27 7:38 AM, Warner Losh wrote:
>
>
> On Mon, Jan 27, 2020 at 8:17 AM Steve Summit <scs+ls at eskimo.com 
> <mailto:scs%2Bls at eskimo.com>> 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
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20200127/e51e6be3/attachment-0001.html>