[buug] anything I need to do: Re: Leap second cometh: 2016-12-31T23:59:60+0000 2016-12-31T15:59:60-0800

[Michael Paoli]

> From: "Ian Zimmerman" <itz at primate.net>
> Subject: Re: [buug] Leap second cometh: 2016-12-31T23:59:60+0000  
> 2016-12-31T15:59:60-0800
> Date: Sat, 3 Dec 2016 16:30:25 -0800

> On 2016-12-03 10:33, Michael Paoli wrote:
>
>> Leap second cometh.
>
> So, is there anything I need to do to defend myself, on a reasonably
> well behaved distribution?

Well, for now, that time is again past (the leap second happened at
midnight ... UTC / GMT0).  But reset assured, it will come again.

For Unix/Linux, if you've got a reasonably well behaved operating
system / distribution, and you're reasonably current on
updates/patches, and your applications are well behaved, and if you and
your applications aren't concerned about quite accurate/synchronized
time more accurate than within about one second, then you probably have
nothing to worry about.  If some of that doesn't apply, or you're
otherwise interested/curious, read on.

Leap second - once upon a time, the second was 1/(24*60*60) of a
solar/astronomical day (or at least a well averaged one).  That,
however, was a problem, as the second was - and is, fundamental unit of
time measurement and, well, days just aren't that uniform.  As it
became possible to much better and accurately measure time, the second
was redefined ... atomic clocks 'n all that.  That left an itty bitty
problem - getting civil time to stay reasonably in sync with
solar/astronomical time.  So, to solve that: leap second.
https://en.wikipedia.org/wiki/Leap_second
(Which is much better than the old situation - where the length of the
second was varied ... egad! - yeah, that'd surely screw up your highly
accurate physics timing experiments ... not to mention constant speed
of light in vacuum, etc. - so yes, the second needed to be fixed to be
a fixed and accurate interval of time.)
But then there's computers, and Unix and Linux.
Per POSIX, for the most part, Unix/Linux sort'a kind'a ignores leap
seconds:
https://en.wikipedia.org/wiki/Unix_time
System time in Unix/Linux is seconds since the Unix epoch - *not
including leap seconds*.
Ah, but can't ignore them entirely - they have to be dealt with
*somehow*.

So - *somehow* - that extra leap second has to be "inserted"* to make
POSIX and all else with Unix/Linux happy.
*theoretically a leap second can be negative - the *removal* of a
second - but thus far that's never occurred, and is unlikely to occur.

So ... what happens on Unix/Linux, with leap seconds, and how is that
all dealt with?  Well, it depends.

First of all, if you've got old unpatched stuff, it may be dealt with
very poorly - notably some leap second related bugs can cause
crashes/hangs or the like.  And even if you're running old crufty
software, there are work-arounds ... at least for potential leap second
issue(s).  And even if you have quite current patched stuff, that
doesn't fully guarantee one has zero bugs related to leap second - in
which case work-arounds can be useful - but there are tradeoffs.

So, dealing with leap seconds.  Various approaches.

First of all, how many seconds per minute and what's returned by the
various library calls and such?  There are up to 61 seconds per minute,
so, the seconds after the minute can be in the range [0..60] - not just
[0..59].  If the software can't handle that 61th second, e.g.:
23:59:60 - then it's broken/buggy ... but again, there are work-arounds.
Likewise for software/libraries that convert time specifications,
including seconds after the minute, etc. - to system time - they need
to also handle a time specification given with leap second data
(however, results of putting in that extra second, or portion thereof,
for any minute that doesn't include a leap second or could not even
possibly be a leap second, may be unspecified - but even in such cases,
software ought do something reasonable).

So ... what's Unix/Linux do about leap second?

In the "bad old days" ;-) - totally ignore it - one would just need to
set/adjust the system time if/when it was off.  At first one could
merely set it to some specific time - nothing else was available "way
back then" - as superuser ("root") - one could use the date(1) command
to set the time - the time was specified, it was converted to seconds
past the Unix epoch, and the clock was set to that (using stime(2)),
and that's all there was to it - no more, no less.  Then capabilities
were added to slew the clock - one could speed it up or slow it down -
so if it was off, it could be adjusted in a manner generally much less
disruptively - but there still wasn't a way to directly add a leap
second - one was still limited to setting the clock, and/or slewing it.

Then along came ways to sync system time to some other time source,
e.g.  some reference time.  Nice - no more manually mucking about with
clocks, right?  Hassle and thought free?  Uhm, ... almost, but not
quite.  Even well set up and synced with NTP - there are those leap
seconds to deal with.  So - how is that done, and what does Unix - or
your Linux distribution do, and do by default?  Well, defaults vary -
and even behavior of various NTP source clocks vary!  And again, there
are tradeoffs.

Some of the various methods from old (ancient) school, and most/more
risk adverse, to newest-fangled most accurate:

(Mostly) ignore it, bury head (/system clock) in sand and pretend it
doesn't exist:

Shut systems down well before leap second.  Start them up again well
after.  Clock can be jumped to correct time at restart, or (if
available) slewed to correct time.

Leave systems running, but have them (mostly) oblivious to leap second:

disable/remove/clobber anything that'd make the system think a leap
second would occur.  Don't have data/flags present or set to tell the
system there's a leap second:

For any time sync, either:

disable it well enough in advance, and reenable after (clocks can then
either jump, or slew, to the correct time, depending upon the actions
taken and/or how configured), or

have it "smear" time - using time source (e.g. "smear"ed NTP), that
adds the extra second by slowing the clock - but only by a little bit,
over a fair stretch of time (typically over 1000s to 24h), so it
generally doesn't cause other issues.  This has advantage of keeping
clocks in sync - at least within, e.g. an organization or
organizations, where all are using the same smear, and while avoiding
hazards of more accurately processing a leap second - but has the
disadvantage that those clocks will be up to about one second (or at
least 1/2 of a second) off through that smear transition.

NTP & slew (ntpd -x) still gradual, but generally much faster than most
of the "smear"s noted above, clocks stay accurate and synced up to the
leap second, after that clocks slew towards correct time at ntpd+kernel
maximum slew rate, which is generally "slew rate of typical Unix
kernels is limited to 0.5 ms/s" (ntpd(8)) - so that takes approximately
2,000 seconds for the clocks to get back to the correct time.

"jump" - kernel leap second time discipline.  If using ntpd without -x
option, and with accurate ntpd source clock and one that passes along
leap second information (there's a flag in the NTP protocol), or with
ntpd given leap second information (ntp.conf(5) leapfile), or by other
software that does similarly, and with capable kernel (e.g. non-ancient
linux), a leap discipline flag is set and passed along to the kernel.
That tells the kernel we have a leap second coming up, and when it
occurs, to effectively "insert" the leap second.  Now, since with POSIX
and system time, as far as POSIX is concerned, the leap second doesn't
exist.  What this does with Linux and other Unix and BSD, etc. kernels,
may perhaps be implementation dependent (maybe if I get a bit of time,
I'll test/investigate a bit more closely). ...

This is where I may not fully know the implementation details (please
feel free to add/correct - may also vary depending upon various kernels
- Linux and/or others).
Essentially, kernel with flag set, will have correct time up to one
second before leap second, and again after leap second.  And ... the
two seconds of time from 23:59:59 ... 23:59:60 ... 00:00:00 - where two
seconds of real time elapse, but the POSIX second (Unix time - seconds
since epoch) only goes up by one second?  I've read different things,
but sounds like that second of system time - two seconds of real time -
the system clock runs at half speed, or it might effectively "repeat"
that POSIX second (the second part wouldn't change, but would last two
real time seconds, however the fractional portion of time past the
second would repeat), or it could run at realtime/speed, up until right
near the end of that second - then run super slow at the tail end of
that second - enough to effectively insert the leap second, and then
resume running at realtime rate thereafter - being again in correct
sync to realtime at the very end of the leap second.  Whichever
approach - or any - is imperfect, but these are among the "most
accurate" - time is kept fully accurately, except for a slight bit of
funkiness for at most, two seconds of real time.  Also, much software,
and many things on Unix/Linux etc., often don't do well if the actual
system time goes *backwards* - so, if the second is repeated, that can
be problematic for some things - but since the POSIX second itself
doesn't go back, that part isn't repeated - no jump in time there - but
factional second portion could repeat if the second, effectively as a
whole is repeated.  And also, if that system time just goes twice as
slow, taking two seconds of real time for one second of system time,
for those two real seconds (or alternatively going real slow at the
end), anything quite sensitive to the rate of system time passing could
have issues (think of your real-time kernel accurately syncing the
rotational speed of a massive industrial metal disk that's to be kept
rotating at precisely 6,000 RPM ... "oops" - what if you're a power
generating company and you have to keep your multi-Megawatt
hydroelectric generator running at quite precise constant speed to stay
synced to a grid at precisely 60 Hz so not only can power be
transferred (by slight adjustments to phase/amplitude) - but you have
the responsibility of accurate time - and keeping the entire country's
motor driven AC synchronous clocks properly in sync - any sync changes
and you alter thousands or millions or more clocks around the country
or more and mess up folks time standards and may cause equipment/timing
malfunctions, etc.  I even have an older digital alarm clock radio that
keeps its time by counting the AC power line cycles - I presume PG&E
maintained 60 Hz, and that clock "lost" one second (it has no way to
insert the second ... other than me setting the clock ... or unplugging
it briefly - so it misses those AC cycles - but the DC capacitors don't
lose so much charge that the clock drops time state ... and yes, that
clock - can do that to slow it up to a maximum of about 10 seconds that
way ... so, yes, I can "insert" a leap second for it by unplugging its
AC power for precisely one second).

So ... if your system and software is reasonably patched/updated, or
you're using relevant work-arounds, and you're not concerned about time
being incorrect or out-of-sync by up to about a second, and your
software can handle the 61st second with the minute (or you've done the
work-arounds so your system won't experience that), and you can deal
with two seconds of real time taking a second of system clock time and
possibly the fractional portion of second repeating (or you've applied
work-arounds so you don't see that), and you don't have an issue with
these discrepancies of clocks and real-world time of up to about a
second, well, then you've pretty much nothing to worry about regarding
leap seconds.  But if you've got bad/old/broken/buggy software, and
haven't at least applied work-arounds, then you might experience
issues.  Even if you have nice current well patched software, there's
small probability one might have issues if work-arounds aren't applied,
but that probability is low - and work-arounds trade off accuracy for
stability and predictability.  For Unix, Linux, etc., unless/until
POSIX comes up with a "better" solution, we'll continue to have these
less than 100% fully ideal leap second "solutions".  Note the
fundamental problem with POSIX seconds since Unix epoch and civil time
- for any number of seconds since the epoch, have to be able to convert
that to/from civil time - including times in past (at least since
epoch), and times in future (at least to the end of Unix time).  The
issue with that is we don't know well in advance what leap seconds
we'll have.  So for that reason, POSIX mostly pretends that leap
seconds don't exit.  Oh, and fun with timezones ... the right/
timezones include leap seconds, whereas the others don't - yeah, I
haven't looked into exactly how those timezones reconcile with POSIX
... or if they do.

Oh, and there are some alternatives that have been proposed.  Most
notably, totally doing away with leap seconds ... but that then breaks
everybody's sun dials and solar and astronomical time (as it is, with
leap seconds, civil time is kept within 0.7s of solar/astronomical
time).  Just my humble opinion, but I think it's better that we have
leap seconds than not.  I think we just need better evolve our software
and systems to deal with them.  Perhaps there will be some extensions to
POSIX at some point, to allow for better handling of this.  We're
*almost* there - really just need better ways to deal with leap second
itself - all else with POSIX and time is already pretty well addressed.

Happy New Year!  Did y'all put your extra second to good use?  ;-)

http://buug.org/pipermail/buug/2016-December/004165.html
adjtimex(2)
adjtime(3)
stime(2)
date(1)
clock(3)
ctime(3)
difftime(3)
gettimeofday(2)
gmtime(3)
localtime(3)
mktime(3)
strftime(3)
strptime(3)
time(2)
time(7)
timegm(3)
tzset(3)
utime(2)