It seems we are about to have a leap second added to UTC (the international time standard). In this article https://www.theguardian.com/uk-news/2016/dec/30/new-years-eve-countdown-to-take-second-longer-than-normal it says that the second is to be added at 23:59:59 New Years Eve, but it is written from the perspective of the UK where we are on UTC+0 because the Prime Meridian passes through Greenwich in East London. My question is what happens in other time zones. Is the second added at the same moment worldwide, or is it propagated over the course of 24 hours as 2017 rolls east-to-west?
It happens worldwide at the same moment. Since all local times are defined as + or - UTC, when the UTC changes, so does everything else.
Also, excellent username + subject combo! 
I tried to see that on Mac OS 10.12.2 (Sierra), but repeated invocations of date -u jumped straight from 23:59:59 to 00:00:00 without the expected 23:59:60 in between. My guess is that Apple didn’t implement David Madore’s suggestion of having a separate clock specifier within the clock_gettime() routine, or if they did, the date command wasn’t programmed to use it.
Question to the Brits here (and to others whose local time coincides with UTC): This leap second means that, in UTC, the last minute of 2016 , i.e. 23:59, had 61 seconds rather than 60. Do TV stations take account of that when they show countdown clocks for their new year on their screens? Do they proclaim the new year on screen a second after 23:59:60 rather than a second after 23:59:59?
Did anybody with a shortwave radio tune into WWV and listen to the interval?
I would expect that TV networks might have had an interval or an overlap in theeir programming, since all commercials, etc. are timed to the second, and are triggered to start and stop according to digital timing, with the leap second not accounted for. In a US time zone this would have occurred at 5 or 6 pm. If the network was feeding a program according to leap time, and the local station running an ad for :30 starting at 5:59:30, the ad would end a second before the network show started.
I watched the countdown on BBC1 but I could not tell if there was a delay or not. I doubt that these things are timed to the nanosecond anyway.
They could punt the issue by using TAI (International Atomic Time)* as their time standard, because TAI does not recognize leap seconds. Neither does the time reported by GPS satellites, which was synchronized to UTC on January 6, 1980, and is therefore offset from TAI. Therefore, both of those clocks are drifting from UTC (Coordinated Universal Time), which is the time standard which does recognize leap seconds. WWV and similar time services report UTC time.
To summarize:
BEFORE THE 2016 LEAP SECOND: GPS-UTC IS 17 (GPS AHEAD OF UTC BY 17 SECONDS)
AFTER THE 2016 LEAP SECOND: GPS-UTC WILL BECOME 18 (GPS AHEAD OF UTC BY 18 SECONDS)
As of June 30 2015, and until the leap second of December 31 2016
TAI is ahead of UTC by 36 seconds.
TAI is ahead of GPS by 19 seconds.
GPS is ahead of UTC by 17 seconds.
After December 2016,
TAI is ahead of UTC by 37 seconds.
TAI is ahead of GPS by 19 seconds.
GPS is ahead of UTC by 18 seconds.
None of these clocks are wrong, and they’re all measuring the same thing, in an abstract sense. The fact they’re all different is, therefore, not a problem.
*(It is an ironclad rule that these abbreviations be a split-the-difference between French and English, much like how we have three different absolute scientific time standards which will never again agree with each other.)
There is certainly no problem for GPS … as GPS broadcasts “Currently 18 seconds ahead” and broadcasts warning about scheduled leap seconds months before… (so the message is “leap second scheduled 1st July 2018” or some such… months before it actually occurs… ) so that GPS receivers can actually know the CORRECT time… precisely UTC accurate.
Whether or not the actual time stamps broadcast by GPS are UTC OR GPS + leap second correction, or they were leap second free in the past … the functional effect is that it NOW broadcasts UTC and info about upcoming leap seconds… (so that it can know that you will be a second early on that route preview you are using to time your missile strike !)
See Leap Second Implementation Confuses Some Receivers - GPS World : GPS World
UTC time is no more or less correct than any other time standard. We know this because they’re all time standards.
True.
But the point was that amateur folks might become confused about the details. And that some cheap-ass GPS receivers might show you raw GPS time while mislabeling it “UTC”. Leading to further confusion.
Isilder’s point was that the end user doesn’t necessarily have to do the 18 second conversion themselves. It’s possible, and indeed quite likely, that the receiver does it for you. And does it both precisely and accurately.
In technical parlance, “GPS time” is an implementation detail that ought to be encapsulated below the API level and definitely below the UI level on almost all devices. As such, bringing it up can serve to confuse more than to enlighten.
And here I was going to wait a few months until 2017 calendars went on sale …
I would assume that any device that connects online to keep time accurate will just wind up being set back a second the next time they update, rather than coding in a #:59:60 variation.
I also know that Google actually spreads the new second throughout the day rather than adding a new second and messing up their system.
I did that once in the 1980s. It was strange to note the extra second. I also recorded it on a cassette (now lost) so I could double-check it.
From Leap second - Wikipedia, see “Screenshot of the UTC clock from www.time.gov during the leap second on December 31, 2016.” https://upload.wikimedia.org/wikipedia/commons/8/87/Leapsecond2016.png
So, I was thinking about this, and came up with the following conclusions, which I share with you:
MS Excel or SQL Server time, time, which are sort of derived from Lotus 123 time and other sources, represent days by integers, and seconds by fractions of a day. So intervals always have the correct number of days, and hours, and minutes, but leap seconds are smeared over a day: individual seconds and minutes and hours aren’t quite the right length on leap-second days, and the number of seconds in an interval is “wrong” if the interval spans one or more leap seconds.
Unix epoch time ignores leap seconds. It is gradually getting out of sync with UTC. For this reason, you can’t calculate UTC or local time intervals by comparing epock time values: the result is “undefined”. You must use system calls to calculate UTC or intervals. But since leap seconds aren’t predictable in the long term, you must do some kind of system update for every leap second. Unlike MS time, which by definition re-syncs to UTC every day, epoch time never resyncs.
Have I got any of that wrong?
Yes they did, at least on the Jools Holland “Hootenanny” show. He mentioned the leap second and then did the countdown like this: “10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 1, Happy new year!”
(Of course, the show is pre-recorded well before New Year, but they take the timing pretty seriously. Shame that with digital TV, the clocks are never properly accurate these days!)
Actually, some Linux os’es (most I think) had to be patched. We run CentOS at work and we had to patch ~600 servers, otherwise they lock up if the clock is set back a second during an ntp update*. We run a private ntp server that sync s to a public ntp source.
Smearing the second is a neat idea.
Slee
- I read the alert on it a while ago but forgot why the machines freak. I was more worried about updating all the servers.
FYI: Cloudflare’s DNS proxy service got messed up a bit by the leap second.