[TUHS] Leap Second

[Steffen Nurpmeso]

Warner Losh <imp at bsdimp.com> wrote:
 |On Wed, Jan 4, 2017 at 6:32 AM, Steffen Nurpmeso <steffen at sdaoden.eu> \
 |wrote:
 |> schily at schily.net (Joerg Schilling) wrote:
 |>|Tony Finch <dot at dotat.at> wrote:
 |>|> sds <stephen.strowes at gmail.com> wrote:
 |>|>> Important question: did anybody have an "exciting" new year because \
 |>|>> of a leap
 |>|>> second bug?
 |>|>
 |>|> I've been collecting failure reports on the LEAPSECS list
 |>|
 |>|https://blog.cloudflare.com/how-and-why-the-leap-second-affected-cloudfla\
 |>|re\
 |>|-dns/
 |>|
 |>|"go" seems to have a related bug.
 |>|
 |>|BTW: The POSIX standard intentionally does not include leap seconds \
 |>|in the UNIX
 |>|time interface as it seems that this would cause more problems than \
 |>|it claims
 |>|to fix.
 |>
 |> I think it is a problem, or better a gap, a void, with the current
 |> standard that software has no option to become informed of the
 |> event of a leap second for one, but further more that CLOCK_TAI is
 |> not available.
 |
 |And even if it was, nobody would use it. It's not used in legacy code,
 |and the subtle differences between the different CLOCK_xxx aren't well
 |enough documented enough for programmers to get it right. And even if
 |it were, the issue is a lot more subtle than that. If you use
 |CLOCK_TAI, then if the system has the proper TAI offset to UTC,
 |calling things like timegm will produce a time that's 40s different
 |than the current UTC time if you aren't also running the proper
 |"right" timezone files, and people will think your code is buggy. But
 |if you get a UTC time, then you have an ambiguous encoding of the leap
 |second (though CLOCK_UTC, where implemented, tries to cope with that
 |by having a denormalized ts_nsec field). It's a big can of warms since
 |most programmers expect time to be a uniform radix, and UTC transforms
 |time of day into a non-uniform radix on an unpredictable timetable.

You quote the Markus Kuhn proposal.  We would need more time
interfaces that work with clockid_t, like much more differentiated
and known people have developed not few years ago.  But i really
would like to see this basic and portable software infrastructure
improved.  I personally am bothering with the natural language
support the most (and if it is as simple as wcwidth(3) missing
from ISO C), but this is also true for time and date management.

I really wonder why no University ever took part and did it right.
That is such a crucial part?!  For example, the Berlin (and
Hamburg) Universities supported "significantly" the RIOT-OS
development -- and that is a complete operating system!

 |But that's starting to get far afield for the historical unix group...
 |
 |> I think it would make things easier if software
 |> which wants just that can get it, e.g., for periodic timer events
 |> etc.
 |
 |CLOCK_MONOTONIC already exists for these things, and programmers still
 |screw it up :(

For the context of this list that clock is a new invention. 
I've used gettimeofday(2) for my small thing and am thus guilty.

 |> This is surely not a healing given that most timestamps etc.
 |> are based on UTC, but i think the severity of the problems could
 |> possibly be lowered.  Especially now that multi-hour smears seem
 |> to become used by big companies it seems to be important to have
 |> a correct clock available.  This is in fact something i don't
 |> really understand, at _that_ level that is to say.  If, e.g.,
 |> Google and Bloomberg both would have stated instead that they
 |> slew the leap second, then only a single second would have been
 |> affected, instead of multiple hours.
 |
 |You can't just slew the one second. It introduces too large of a
 |frequency error in the time base. ntpd will view it as a large error
 |and freak out. Programs that want to sleep for 100ms will wind up
 |sleeping for 200ms instead, which could be a big problem. With the

Yes, that is understood.  But if you have absolute control over
the environment then you most likely can also verify that or
whether it can be driven with a very short slew or not, that is
what i have meant.  In fact i just followed the RedHat link you
have posted on the leapsecond list, and was lead from there to
a page with the several possible options, and how Chrony and NTPD
behave for them.  Note that for me personally this really does
no(t) (longer) matter (except for my hard-NTP driven VM-based
server), the low-level software i use has a very unprecise
hardware clock, even so much that i practically have to set the
time hard because NTP adjustments don't really make it (after
hardware wakeup).

 |slew over several hours, programs wind up sleeping for 100.01ms
 |instead, which is down in the noise of the error you get from a sleep.
 |Google is trading a small phase error and frequency error against the
 |real UTC timestamp to maintain a well-defined monotonically increasing
 |time series with no repeating seconds as its method of coping with
 |POSIX's deliberate decision to not define what happens over a leap
 |second, provide no encoding for a leap second and generally specifies
 |an interface in which it is nearly impossible to get the leap second
 |pedantically correct. Makes one question whether leap seconds are a
 |good idea or not, but that's a political discussion for another group.

I absolutely think that the knowledge that mankind gained over so
many years and which manifests in the leapsecond, this is a cultural
achievement that cannot be overestimated, and there i do not even
incorporate the social importance that i think is involved.

--steffen