
A positive leap second will be introduced at the end of June 2015 - TheSwordsman
http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat
======
adamtj
Why don't we just switch from UTC to TAI and put the leap seconds in our
localtime offsets? It makes all the problems go away, or else reduces them to
problems we've already solved for handling daylight saving time.

If you think about it, leap seconds are no different than daylight saving
time. The only differences are that daylight saving time usually has 1-hour
granularity and is occasionally redefined by your government, where leap
seconds have 1-second granularity and are occasionally redefined by Mother
Nature.

We already know how to deal with repeating seconds and minutes (alternatively,
with minutes or hours that are too long). Those happen during daylight saving
time changes, but the ambiguity disappears when switching to UTC. We already
record timestamps and communicate with UTC, applying a localtime offset for
display or user input. That's a solved problem.

Further, we know how to change the localtime offset. Most timezones do that
twice a year. We also know how to handle timezone definition changes because
ignorant legislatures sometimes modify when the daylight saving time switches
occur.

So, why don't we switch from UTC to TAI as an underlying time standard? When
UTC leap seconds occur, we can treat them somewhat like a government
redefining its timezones. US Eastern Time then changes from
"TAI-05:00:35/TAI-04:00:35" to "TAI-05:00:36/TAI-04:00:36".

If two UTC clocks are synchronized, then one accounts for a leap second and
the other misses it, the clocks will no longer be synchronized. If they were
TAI clocks, they would still be synchronized and both would still record and
communicate correct timestamps. It's just that one would display localtime
incorrectly. But, you would immediately know that was the case when you see
that the offset is a second behind. Missing a leap second would be like having
your computer is set to the wrong timezone, and would be just as easy to fix.

~~~
skrebbel
Because humans. Remember how confusing and difficult to find those bugs are
where you forget to convert timezones that are, say, <3 hours away from one
another? This must be very familiar especially to all African and European
coders, where we're caught by this every time we forget to convert to/from UTC
somewhere. It's easy to not notice it, while coding with some test data, when
your software displays a time only one or two hours off. I bet many UK coders
only notice their bug when summer begins. I'm not sure whether you valley
people recognize this as well, but I'm sure you can imagine.

Now, instead, imagine things being only a few _seconds_ off, instead of entire
hours. How big is the chance that the bug would be caught before things hit
production? What if, in some cases, seconds actually matter?

I think it's just asking for trouble.

To me, this is a bit like proposing binary protocols and not text protocols
because it's obviously technically superior. It's a good idea until you factor
in that software is made by humans.

~~~
eleumik
Almost joking, but in my experience europeans (also not coders) are stronger
in language-localization and currencies, while americans (also not coders) are
strong in timezones ;-)

------
NelsonMinar
Last time we had a leap second in 2012, it crashed a whole lot of web servers.
There was a bug in Linux kernel threading that MySQL and Java both triggered.
Please forgive the self-link, but lots of details from the time on my blog:
[http://www.somebits.com/weblog/tech/bad/leap-
second-2012.htm...](http://www.somebits.com/weblog/tech/bad/leap-
second-2012.html)

Leap seconds are a fact of timekeeping. Google's approach of slewing the clock
seems like a robust way to implement it if you don't trust the operating
system to do it right. [http://googleblog.blogspot.com/2011/09/time-
technology-and-l...](http://googleblog.blogspot.com/2011/09/time-technology-
and-leaping-seconds.html)

~~~
iwwr
>Last time we had a leap second in 2012, it crashed a whole lot of web
servers.

That exposed a bunch of underlying bugs, didn't it? It may be a good thing in
the long run than without it, especially with a one year's head start.

~~~
NelsonMinar
That's the optimistic view. But leap seconds also caused problems in 2008 and
2005. It seems more likely we'll just find some exciting new bugs. Hopefully
not one that b0rks the whole kernel though.

------
uniformlyrandom
> Daniel Gambis

> Head

Daniel is clearly missing out on an opportunity to have the coolest title
ever.

'Head of Earth Rotation', or 'Earth Rotation, Director of' would sure look
nice on a business card.

~~~
xg15
Being able to address, in all seriousness, the "authorities responsible for
the measurement and distribution of time" seems like a good second place to me
though.

~~~
joshschreuder
Daniel Gambis, Time Lord would go well on a business card.

------
repsilat
This leap second business seems like a pretty dreadful idea. Considering
timezones are way off-base all around the world as it is[1], it seems a lot
simpler to just let the clocks drift for a while. One less weird thing in our
operating systems, much less opportunity for bugs in all kinds of code that
deal with times.

The set of people who really care about solar time "down to the second" is
smaller than the set of people who'll be put out by 23:59:59 not being
immediately followed by 00:00:00, and most of those people probably want sub-
second accuracy anyway. Astronomers complaining about the clock time being
wrong is exactly the same as farmers complaining about daylight savings.

1:
[http://poisson.phc.unipi.it/~maggiolo/index.php/2014/01/how-...](http://poisson.phc.unipi.it/~maggiolo/index.php/2014/01/how-
much-is-time-wrong-around-the-world/)

~~~
gcb0
i for one vote to a base 10 system that takes all that into account.

imagine splitting time not exactly in seasons begin/end (what was the last
time you synched your clocks with a solstice?). no leap seconds. no 28-31
months. no 365+-1 years. even daylight saving time benefits can be worked in
the system if we don't sync 100% with the solar day but skew it just enough
that you get the drift to align things on daylight saving benefits and still
can tell the time by simply looking at the sun.

it's not hard. just nobody has the balls to even suggest this seriously out of
math circles.

~~~
morganvachon
Ever since I was a kid, the concept of a seven day week threw me. Way back
then I came up with a ten day week, three weeks a month, 13 months a year, and
five non-month "holidays" calendar in my head. The five non-month holidays
were (if I recall correctly) summer and winter solstice, spring and fall
equinox, and New Year's Day.

I never could get around the 1/4 day problem, and still had to account for
leap years with a sixth non-month day every four years. It was a fun thought
experiment as a teenager interested in math and science though.

~~~
toast0
FYI, you have reinvented the French Republican Calendar[1], only you missed
out on decimal time (1 day is 10 hours, 1 hour is 100 minutes, 1 minute is 100
seconds; 1 second is 0.864 conventional seconds)

[1]
[http://en.wikipedia.org/wiki/French_Republican_Calendar](http://en.wikipedia.org/wiki/French_Republican_Calendar)

~~~
aragot
Why are you all looking for base-10 hours, when it's rather the base-10 which
is wrong??? Numbers should be switched to base-12. I mean we often need to
divide 1kg by halves, quarters and thirds, and it should fall even.

~~~
cortesoft
We should do base 16, though, so it lines up with binary.

~~~
gchpaco
Not divisible by three, which comes up a lot. 12 is superior.

60 is probably best, tho.

------
jedberg
At least this one is in June. Whenever they do one in December, you have to
suffer through a terrible explanation of what a leap second is from a TV
newscaster, explaining why the ball isn't going to drop for an extra second.

------
tehmaco
This will probably resonate with people here[1]. A brilliant video by Tom
Scott for Computerphile, where he starts to explain what coding timezones
correctly is like and by the end of it is in full polite-mini-rant-mode :D

[1] [https://www.youtube.com/watch?v=-5wpm-
gesOY](https://www.youtube.com/watch?v=-5wpm-gesOY)

------
atonse
I'm curious to see how this affects Spanner (Google's new database that seems
to rely on extremely precisely synchronized time to coordinate transactions).

Anyone on the Spanner team able to comment?

~~~
bluelu
There was a post in the past that google have their own custom timeservers for
their servers, slowly adapting time over multiple days and months, so they are
not affected by this.

~~~
cordite
In their databases that depend on time, they repeat that they use an external
source of time.

It seems like some of their designs are constrained around always non negative
deltas between events, making things append only so their trees or hash tables
are only balanced once when written to disk.

~~~
Artemis2
I haven't read about Spanner, but wouldn't it be possible for their clock to
measure time based on an epoch, instead of using the system based on physical
factors (the rotation of the earth around its axis and around the sun) that we
use?

~~~
cordite
It is probably easier in the long run if the servers had the same time as the
machines that people use, which are regularly updated by their OS's choice of
NTP server, since people run reports and react accordingly.

------
mrgriscom
My personal opinion is that leap seconds have no place in civil timekeeping. I
love them as geeky trivia but in practical terms they are a disaster. They do
solve a real problem of keeping solar time roughly in sync with atomic time
due to the slowing rotation of the Earth, but in today's computer-dominated
and interconnected world inflicting a one-second discontinuity every few years
on millions of systems individually rather than handling it in a central place
is a bad idea. It's like a mini-Y2K several times a decade.

The core issue is we have two different needs: a hyper-accurate count of
elapsed SI seconds, and a day-to-day date/time system that roughly tracks the
position of the sun in the sky. UTC tries to combine these into the same
thing, when they would best be left separate.

For the former, we already have a pure atomic timescale -- TAI -- to handle
this. I would go a step further and not even present TAI as a date and time,
but rather a raw count of seconds like unix time. This is to enforce that TAI
is _not_ civil time, but rather a standard to benchmark and calibrate against.

For the latter, I propose a new time standard that is a transformation
function applied to TAI. The IERS, instead of decreeing leap seconds like they
do now, would instead declare an offset and skew rate that smears the leap
second out over a longer period. Something like: at date X, civil time will be
Y seconds ahead of TAI, and will tick Z% faster/slower until further notice,
where Z is expressed in a simple unit like parts-per-billion or milliseconds
per day. Instead of leap seconds every 18 months or so, with this scheme the
IERS could probably get away with making adjustments once every five years,
and still stay within the 0.9s of true solar time as mandated by UTC.

Any modern microprocessor could handle this transformation trivially. Most
would not even need to as the internal clock resonators in 99.9% of the
world's computers and clocks are less accurate than the skew rate Z. They need
to periodically resync with a master clock anyway and the drift would be
indistinguishable from noise.

To be clear, no one would be changing the length of the second. An SI second
is and always will be an SI second, and high-precision computing and science
will be done with reference to SI seconds. But the elapsed time between
consecutive seconds of civil time will be not quite an SI second, and will
differ by an amount so small that for the purposes of day-to-day timekeeping
is in effect indistinguishable.

~~~
mrgriscom
Adding to my original comment:

Getting rid of leap seconds and being done with it -- effectively setting
civil time to atomic time -- may seem like an attractive alternative that
achieves the same effect without the complications of transformation functions
and skew rates, but it ignores that since the Earth's rotation is continuing
to slow down, the offset between atomic and solar time is going to increase
quadratically. While the first leap hour is 900 years out, the next one after
that is only another 400, then 300, then 250... Someone is going to have to
solve this problem for good eventually, and that will either involve applying
the correction continuously as in my scheme, thus eliminating the quadratic
compounding of the error, or eventually re-defining the second at some distant
point in the future to match the Earth's rotation (and thus starting the
situation over from scratch).

------
olympus
This really messes with some of the stuff I do at work with test
instrumentation since we use GPS time in the field but our computers use UTC.
We had a problem late in 2014 when one of our instrumentation techs was using
an old instruction manual and he was converted his data using a 14 second
offset between GPS time and UTC, instead of the correct 16 seconds. Now we'll
have to issue all new instruction manuals to the technicians-- or maybe we can
just fall back to a 2011 version that had a 15 second offset.

~~~
masklinn
> or maybe we can just fall back to a 2011 version that had a 15 second
> offset.

Won't the new offset be 17s? The offset would only diminish if a negative leap
second was enacted which has yet to happen.

~~~
olympus
I must have misread the article. I thought a positive offset was different
from all the other ones. In that case, it's still a new manual version, but
much less unusual.

------
jgstultz
If folks are (reasonably) feeling nervous about this, I've got a test program
lets you insert leap seconds to test your application behavior. Would love to
hear about anything folks see that might point to any remaining kernel issues.

[https://github.com/johnstultz-
work/timetests/blob/master/lea...](https://github.com/johnstultz-
work/timetests/blob/master/leap-a-day.c)

------
ars
Is there an NTP command to see if NTP was informed about the change?

~~~
jzwinck
It's not quite that simple, but I think this is a good explanation:
[http://support.ntp.org/bin/view/Support/ConfiguringNTP#Secti...](http://support.ntp.org/bin/view/Support/ConfiguringNTP#Section_6.14).
(TL;DR: don't worry about it).

------
AdamN
Everybody's talking about the time situation here, but what about the fact
that the world's clocks will gain a second and the site announcing the fact
isn't even signed and secure. It seems like the message should definitely have
a cryptographic signature and that the site should be reachable via https.

------
micro-ram
[http://www.leapsecond.com/java/gpsclock.htm](http://www.leapsecond.com/java/gpsclock.htm)

A cool realtime clock that shows the offset the GPS satellites work from,
which do not include leap seconds.

------
gweinberg
It could be worse. They could have leap tenths of seconds ten times as often.

~~~
nullc
That would arguably be better, the smaller distortion would be less likely to
break things and the frequency would make it much more likely that things were
tested against it.

(Of course best would be to have none at all, and accept that several thousand
years from now people-- if people still exist then-- may choose to slip the
timezones by one hour to correct the drift.)

------
emptybits
Yay, more sleep!

Wait... ( _very_ briefly thinking about broken assumptions, date calculations,
month-end assumptions, 0:59 versus 0:60 vs. 0:00, ...) dammit, I just lost
more than I gained! Thanks, France!

------
ck2
Ugh not again
[http://phys.org/tags/leap+second/](http://phys.org/tags/leap+second/)

Quantas crashed last time. I mean their computers, not the planes.

~~~
caf
There's no 'u' in Qantas - it was originally an initialism.

------
tonyhb
Thanks for the update. Writing a Go program now which is pretty sensitive to
these, and it's pretty annoying to have to consider them in your tests.

------
yoha
Incidentally, time.nist.gov is down. It hosts a list of leap seconds at
ftp://time.nist.gov/pub/leap-seconds.list.

------
billpg
Remember when we'd have one of these almost every year? Those were the days.

Kids today... Get off my lawn.

~~~
repsilat
They really have dropped off since 1999:
[http://en.wikipedia.org/wiki/Leap_second#Insertion_of_leap_s...](http://en.wikipedia.org/wiki/Leap_second#Insertion_of_leap_seconds)

------
nullc
Hurray, time to see NTP screw up hosts everyone on the internet yet again.

(Oh wait, the last leapsecond event didn't even involve an actual leapsecond)

------
nchelluri
Does this require a code change?

------
quinndupont
They did say that 2015 would be the year we got time travel. One second is a
little less than anticipated though.

