[TUHS] Leap Second

[TUHS] Leap Second

[Dave Horsfall]

(Yes, a repeat, but this momentous event only happens every few years.)

The International Earth Rotation Service has announced that there will be 
a Leap Second inserted at 23:59:59 UTC on the 31st December, due to the 
earth slowly slowing down.  It's fun to listen to see how the time beeps 
handle it; will your GPS clock display 23:59:60, or will it go nuts 
(because the programmer was an idiot)?

I actually have a recording of the last one, over at 
www.horsfall.org/leapsecond.webm (yes, I am a tragic geek),

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Leap Second

[Peter Jeremy]

On 2016-Dec-29 10:59:32 +1100, Dave Horsfall <dave at horsfall.org> wrote:
>(Yes, a repeat, but this momentous event only happens every few years.)

Actually, they've been more frequent of late.

>The International Earth Rotation Service has announced that there will be 
>a Leap Second inserted at 23:59:59 UTC on the 31st December, due to the 
>earth slowly slowing down.  It's fun to listen to see how the time beeps 
>handle it; will your GPS clock display 23:59:60, or will it go nuts 
>(because the programmer was an idiot)?

Google chose an alternative approach to avoiding the 23:59:60 issue and will
smear the upcoming leap second across the period 2016-12-31 14:00:00 UTC
through 2017-01-01 10:00:00 UTC (see https://developers.google.com/time/smear).
Of course, this means that mixing time.google.com with normal NTP servers
will have "interesting" effects.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161229/c8d492e6/attachment.sig>

[TUHS] Leap Second

[sds]

On 29/12/2016 01:21, Peter Jeremy wrote:
> On 2016-Dec-29 10:59:32 +1100, Dave Horsfall <dave at horsfall.org> wrote:
>> (Yes, a repeat, but this momentous event only happens every few years.)
> Actually, they've been more frequent of late.
Important question: did anybody have an "exciting" new year because of a 
leap second bug?

>> The International Earth Rotation Service has announced that there will be
>> a Leap Second inserted at 23:59:59 UTC on the 31st December, due to the
>> earth slowly slowing down.  It's fun to listen to see how the time beeps
>> handle it; will your GPS clock display 23:59:60, or will it go nuts
>> (because the programmer was an idiot)?
> Google chose an alternative approach to avoiding the 23:59:60 issue and will
> smear the upcoming leap second across the period 2016-12-31 14:00:00 UTC
> through 2017-01-01 10:00:00 UTC (see https://developers.google.com/time/smear).
> Of course, this means that mixing time.google.com with normal NTP servers
> will have "interesting" effects.
FWIW, Akamai and AWS are similar (but different) implementations of leap 
second smear:
* 
https://blogs.akamai.com/2016/11/planning-for-the-end-of-2016-a-leap-second-and-the-end-of-support-for-sha-1-tls-certificates.html
* 
https://aws.amazon.com/blogs/aws/look-before-you-leap-the-coming-leap-second-and-aws/

S.

[TUHS] Leap Second

[Tony Finch]

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://pairlist6.pair.net/pipermail/leapsecs/2017-January/thread.html

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Fitzroy, Sole: Easterly or southeasterly 5 to 7, occasionally gale 8 at first
in west. Moderate or rough, occasionally very rough at first in west. Rain.
Moderate or good.

[TUHS] Leap Second

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 798 bytes --]

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-cloudflare-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.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] Leap Second

[Steffen Nurpmeso]

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-cloudflare\
 |-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.  I think it would make things easier if software
which wants just that can get it, e.g., for periodic timer events
etc.  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.

--steffen

[TUHS] Leap Second

[sds]

On 03/01/2017 16:06, Tony Finch 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://pairlist6.pair.net/pipermail/leapsecs/2017-January/thread.html

This is great, thanks!

S.

[TUHS] Leap Second

[Warner Losh]

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-cloudflare\
>  |-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.

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 :(

> 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
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.

Warner

[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

[TUHS] Leap Second

[Charles Anthony]

On Fri, Dec 23, 2016 at 3:08 PM, Dave Horsfall <dave at horsfall.org> wrote:

> Let me be the first to say that the International Earth Rotation Service
> has announced that there will be a Leap Second inserted at 23:59:59 UTC on
> the 31st December, due to the earth slowly slowing down.


A year and half ago, a running Multics emulation (Multics, so slightly on
topic) was crashed by the leap second. An improbable race condition in a in
a messaging library used by the DPS8M emulator fired an assertion, bring
the whole thing down.

-- Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161223/43a34ebd/attachment-0001.html>

[TUHS] Leap Second

[Michael Kjörling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 683 bytes --]

On 24 Dec 2016 10:08 +1100, from dave at horsfall.org (Dave Horsfall):
> Let me be the first to say that the International Earth Rotation Service 
> has announced that there will be a Leap Second inserted at 23:59:59 UTC on 
> the 31st December,

I told a coworker about leap seconds the other day, in the middle of
discussing software that doesn't understand 24:00:00 as a time of day.
For a while, I believe he thought that I was pulling a prank on him.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

[TUHS] Leap Second

[Dave Horsfall]

Let me be the first to say that the International Earth Rotation Service 
has announced that there will be a Leap Second inserted at 23:59:59 UTC on 
the 31st December, due to the earth slowly slowing down.  It's fun to 
listen to see how the time beeps handle it; will your GPS clock display 
23:59:60, or will it go nuts like my last one did (I had to power cycle 
the thing)?

My recording of the last one: horsfall.org/leapsecond.webm .

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."