* [TUHS] Leap Second @ 2016-12-28 23:59 Dave Horsfall 2016-12-29 0:21 ` Peter Jeremy 0 siblings, 1 reply; 12+ messages in thread From: Dave Horsfall @ 2016-12-28 23:59 UTC (permalink / raw) (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." ^ permalink raw reply [flat|nested] 12+ messages in thread
* [TUHS] Leap Second 2016-12-28 23:59 [TUHS] Leap Second Dave Horsfall @ 2016-12-29 0:21 ` Peter Jeremy 2017-01-03 10:44 ` sds 0 siblings, 1 reply; 12+ messages in thread From: Peter Jeremy @ 2016-12-29 0:21 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 12+ messages in thread
* [TUHS] Leap Second 2016-12-29 0:21 ` Peter Jeremy @ 2017-01-03 10:44 ` sds 2017-01-03 15:06 ` Tony Finch 0 siblings, 1 reply; 12+ messages in thread From: sds @ 2017-01-03 10:44 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [TUHS] Leap Second 2017-01-03 10:44 ` sds @ 2017-01-03 15:06 ` Tony Finch 2017-01-03 15:29 ` Joerg Schilling 2017-01-04 15:54 ` sds 0 siblings, 2 replies; 12+ messages in thread From: Tony Finch @ 2017-01-03 15:06 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [TUHS] Leap Second 2017-01-03 15:06 ` Tony Finch @ 2017-01-03 15:29 ` Joerg Schilling 2017-01-04 13:32 ` Steffen Nurpmeso 2017-01-04 15:54 ` sds 1 sibling, 1 reply; 12+ messages in thread From: Joerg Schilling @ 2017-01-03 15:29 UTC (permalink / raw) [-- 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* [TUHS] Leap Second 2017-01-03 15:29 ` Joerg Schilling @ 2017-01-04 13:32 ` Steffen Nurpmeso 2017-01-04 23:13 ` Warner Losh 0 siblings, 1 reply; 12+ messages in thread From: Steffen Nurpmeso @ 2017-01-04 13:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [TUHS] Leap Second 2017-01-04 13:32 ` Steffen Nurpmeso @ 2017-01-04 23:13 ` Warner Losh 2017-01-05 14:29 ` Steffen Nurpmeso 0 siblings, 1 reply; 12+ messages in thread From: Warner Losh @ 2017-01-04 23:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [TUHS] Leap Second 2017-01-04 23:13 ` Warner Losh @ 2017-01-05 14:29 ` Steffen Nurpmeso 0 siblings, 0 replies; 12+ messages in thread From: Steffen Nurpmeso @ 2017-01-05 14:29 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [TUHS] Leap Second 2017-01-03 15:06 ` Tony Finch 2017-01-03 15:29 ` Joerg Schilling @ 2017-01-04 15:54 ` sds 1 sibling, 0 replies; 12+ messages in thread From: sds @ 2017-01-04 15:54 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [TUHS] Leap Second @ 2016-12-23 23:08 Dave Horsfall 2016-12-23 23:19 ` Michael Kjörling 2016-12-24 1:33 ` Charles Anthony 0 siblings, 2 replies; 12+ messages in thread From: Dave Horsfall @ 2016-12-23 23:08 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 12+ messages in thread
* [TUHS] Leap Second 2016-12-23 23:08 Dave Horsfall @ 2016-12-23 23:19 ` Michael Kjörling 2016-12-24 1:33 ` Charles Anthony 1 sibling, 0 replies; 12+ messages in thread From: Michael Kjörling @ 2016-12-23 23:19 UTC (permalink / raw) [-- 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) ^ permalink raw reply [flat|nested] 12+ messages in thread
* [TUHS] Leap Second 2016-12-23 23:08 Dave Horsfall 2016-12-23 23:19 ` Michael Kjörling @ 2016-12-24 1:33 ` Charles Anthony 1 sibling, 0 replies; 12+ messages in thread From: Charles Anthony @ 2016-12-24 1:33 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2017-01-05 14:29 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-12-28 23:59 [TUHS] Leap Second Dave Horsfall 2016-12-29 0:21 ` Peter Jeremy 2017-01-03 10:44 ` sds 2017-01-03 15:06 ` Tony Finch 2017-01-03 15:29 ` Joerg Schilling 2017-01-04 13:32 ` Steffen Nurpmeso 2017-01-04 23:13 ` Warner Losh 2017-01-05 14:29 ` Steffen Nurpmeso 2017-01-04 15:54 ` sds -- strict thread matches above, loose matches on Subject: below -- 2016-12-23 23:08 Dave Horsfall 2016-12-23 23:19 ` Michael Kjörling 2016-12-24 1:33 ` Charles Anthony
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).