[LEAPSECS] leap seconds in POSIX

[Warner Losh]

On Mon, Jan 27, 2020 at 8:17 AM Steve Summit <scs+ls 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
>
> , 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20200127/e3a86eed/attachment.html>