
June 30th 2012 will be 1 second longer: 23:59:60 - sirwitti
http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat
======
aphyr
POSIX time will jump discontinuously backwards after the leap second,
counting:

59.50 59.75 60.00 60.25 60.50 60.75 60.00

Or, if your clock implementation is not POSIX-compliant but follows Mills'
paper instead:

59.50 59.75 60.00 59.25 59.50 59.75 60.00

It gets weird, though: since this information was only made available
recently, your computer may not know the leap second exists. In that case, its
upstream NTP servers will jump and the local ntpd will slew the clock smoothly
over the discontinuity, IIRC.

OTOH, if your system is aware of the leap second and if you're using the
system clock to calculate intervals (i.e. t2 - t1), expect possibly negative
or zero intervals over this timeframe. If you're calculating rates over a
roughly 1-second interval, divide-by-zero bugs are definitely possible.

On a related note, does anyone know what the Oracle and OpenJDK JVMs do with
respect to System.currentTimeMillis? They _claim_ it's number of seconds since
the epoch, which would imply this timer will not encounter discontinuities.
The only ways I can think of to achieve that are by reading the system clock
state to look for the leap insert/del/doublecount flag, or read a copy of the
leap second table.

[edit] You may be asking, "Why would anyone use a system of time in which two
numbers could refer to the same instant, or one in which a given number could
refer to _no_ time at all? Why not use a time system in which you could
subtract two times from each other to get the interval between them? Or hell,
even a time system _where time always increases_ , you know, so we could
_order events_.

The closest thing we have to such a time scale is TAI
(<http://en.wikipedia.org/wiki/International_Atomic_Time>), which is what most
computer systems like to pretend their clocks are: "the number of seconds
since an epoch".

UTC and POSIX time are adjusted, relative to TAI, to keep the number of
seconds in a given day at a nice "easy" 86400, which is why we're in this
mess. Given that it takes plenty of math to translate a number like
1339696998.435347 into a human-readable date, I think our computers should
just be keeping TAI to begin with and make the whole process easier on
ourselves; but so many systems assume UTC or POSIX time that we're stuck with
it.

~~~
Cushman
I think you're glossing over the fact that POSIX time was _designed_ to
correspond to UTC without needing additional information. Since leap seconds
vary in response to solar and geological phenomena, converting from TAI to UTC
requires an up-to-date lookup table, while the possibility of out-of-order
times can be accounted for in code. I think that's the reasoning behind it
moreso than "math is hard".

~~~
aphyr
You're right; it was designed to make interoperating with UTC easier.

Converting from TAI to UTC requires a lookup table; but consider that this is
_already_ a problem: your local clocks almost always keep time in seconds, not
UTC. In order to keep UTC/POSIX time, it needs regular updates from the
network (NTP) or shipping around a lookup table. This probably made more sense
before large-scale use of NTP, but nowadays I don't know anyone who syncs
their clock to a UTC source.

UTC is in _general_ fucked because two different systems, depending on the
state of their lookup tables, may not agree on what time a given number
represents. This is an especially big problem for embedded systems which can't
receive regular updates; consider that a UTC device manufactured in the 70s
may disagree by up to 30 seconds with a modern UTC clock.

The easiest resolution to the problem is likely to drop leap seconds from UTC
altogether; at which point POSIX, TAI, and UTC can proceed in lockstep
corrected by a fixed offset. [1] Then we can use fixed lookup tables to
compute relationships for the period where we were using leap seconds.

[1] I think. Need to check SI/NIST on this.

~~~
thaumasiotes
I don't see that leap seconds are the problem here (?) -- it seems like the
problem is that we're planning to roll clocks backward instead of having
23:59:60 happen as planned. In contrast, we don't just repeat February 28th
once every four years; we call it the 29th. Why are leap seconds different
than leap days?

~~~
aphyr
Calendars are different than time. It's a little hard to think about; maybe
this will help:

The earth is _sort of_ an inertial reference frame with a single proper time.
It isn't exactly, because it's orbiting, in varying gravity, and spinning, and
has local gravitational changes, etc, but to a decent approximation you can
write down an average time for the whole earth, which is the number of seconds
since the epoch. That time is TAI.

Calendars and dates are things like "June", "Monday, "12:40:70.534 PM", etc.
These are human-friendly names for times, and don't have to be precisely
comparable. It's OK to have "12:00 AM" twice. It's _not_ OK to have "143563534
seconds since Jan 1st 1970 00:00:00" twice.

Calendars are supposed to line up with things like seasons and days. Those
_don't_ last a fixed number of seconds; the earth is always changing. So we
need to have a translation between earth-average-time like TAI, and human
calendars/dates/times. There are a whole bunch of layers of translation
between various time schemes; most of them derive from TAI and add some
offset. UTC is basically TAI plus leap seconds, which keep UTC as "86400 times
the number of _days_ since the epoch, plus the number of seconds since
midnight." POSIX time is derived from UTC. Local time is typically derived
from UTC plus a timezone offset, which can also be modified by daylight
savings time.

Those translations need to change and be updated over time, so we insert and
remove leap seconds, leap days, etc. It doesn't change TAI, but it _does_
change the mapping from TAI to human times.

Back when POSIX was being codified, we made the decision to base most computer
clocks on UTC, which is a human time, subject to changes in that mapping. That
introduces disagreement over what a given time means, discontinuities,
reversals, etc. All of those make it difficult to do calculations around time
correctly.

~~~
Cushman
> UTC is basically TAI plus leap seconds

This part seems a little muddy. UTC isn't a number of seconds since an epoch,
it's a number of hours since midnight, a number of minutes since the beginning
of that hour, and a number of seconds since the beginning of that minute.

Accordingly, UTC can bend the rules by saying, for example, that just this
once the second 23:59:60 exists before midnight. It refers to a different
second from 00:00:00; only when converting into POSIX does that become
ambiguous.

So UTC and TAI agree on the number of seconds since the epoch, it's just UTC
doesn't encode that number in the current time. Going the other way, TAI
doesn't encode the current solar time. You need a lookup table either way.

------
JonnieCache
At midnight on NYE 2008/9 we dialed up the speaking clock, and there actually
was an extra beep. It was pretty cool, and we felt a brief moment of
existential nausea when we suddenly felt our size in relation to the solar
system.

(I'd like to point out that after that we did go to a massive party.)

------
tazzy531
How Google handles leap seconds (by lying to the software):

[http://googleblog.blogspot.com/2011/09/time-technology-
and-l...](http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-
seconds.html)

~~~
adamsmith
Why use cosine to interpolate v.s. a linear smear?

~~~
ajross
The cosine is pretty much the perfect interpolation function when you want the
derivatives to be zero at the boundaries. It's by definition frequency-bound
(to itself, of course). It's derivatives are defined and continuous to any
degree you want. And it's easy to express and understand. You pick other
functions only when it's too expensive.

------
rayanm
That should give me more time to submit a conference paper on June 30.

------
jessriedel
The wikipedia article on International Atomic Time is worth reading.
<http://en.wikipedia.org/wiki/International_Atomic_Time>

------
DanWaterworth
I wonder how many people will be woken in the middle of the night by bugs
caused by this.

~~~
Cushman
This is definitely something you should worry about if you rolled any of your
own time code. The POSIX standard is consistent across days, including leap
seconds. That means that your Unix timestamp will jump back a second: it will
go from 1341100800.9...[0] to 1341100800. If you're relying somewhere on
seconds being continuous, or on a one-to-one mapping between timestamps and
seconds, this could fuck things up.

Although 1341100800 refers to two seconds, when converting to UTC it should
always become 00:00:00. Your implementation may not be conforming to the
standard, though. Make sure to test.

(I'm sure if you rolled your own time code, you already know about this stuff.
Probably other folks are curious though :)

[0] I think this is the second we're talking about, not positive though.

~~~
arohner
I've found or read about bugs in nearly every stdlib time library I've ever
worked in, except Joda time[1].

If you rolled your own, you should worry _more_ , but you should still think
about it even if you didn't roll your own.

[1] Joda is awesome, and _by far_ better than any other time lib out there,
but even they have bugs they're fixing in JSR310
(<http://jcp.org/en/jsr/detail?id=310>)

------
3pt14159
Guys do the right thing. If your app is very sensitive to bad data (say
financial) just throw up a temporary "down for quick maintenance" page for a
couple of seconds and you are good to go.

~~~
btipling
Downtime affects SLAs and there isn't a lot of breathing room depending on
your 9's[1]. In addition, bringing something down has its own problems and are
you just advocating bringing down the user interface or should everything get
shut down, like the entire stack? All the services, queues, databases, block
storage, etc?

[1]
[http://en.wikipedia.org/wiki/High_availability#Percentage_ca...](http://en.wikipedia.org/wiki/High_availability#Percentage_calculation)

------
ChuckMcM
I think it would be an interesting PR campaign to ask people what they would
do with 1 more second. if time is money, how much money do we inject when we
add a second to the year?

Of course we wouldn't have this problem if we just counted seconds from some
particular point in space time moving forward. Who cares if the Sun is exactly
overhead at noon anyway :-)

------
acomjean
Thank goodness I don't have to work on time anymore. Zulu time, sidereal_time,
UTC, GPS Time... Phone calls from work at odd hours..

I do like GPS time. It keeps going at a constant rate like all good time
should. Time differences are easier in GPS, you don't have to worry about
pesky leap seconds....

Sidereal time is the most interesting from a cosmic sense.

------
pooriaazimi
A hackerish question: how can you take advantage of it? Say, in stocks or
online transactions?

 _(I haven't got time to read the article right now (but will do in a week
when I'm less busy) and have little to zero experience with times, so forgive
me if it's something that's been discussed in the article. I'm just curious.)_

~~~
TazeTSchnitzel
SSL certs or something, maybe?

~~~
vlisivka
SSL certs issued at :60 may have problem with validation. Just reissue them.

~~~
TazeTSchnitzel
I guess that's not very interesting, then :/

------
bajsejohannes
Does anyone know where you can subscribe to future leap second announcements?

~~~
acomjean
We were in the US so we used to get it from the Naval observatory.

<http://www.usno.navy.mil/USNO/time/master-clock/leap-seconds>

they get if from IERS

<http://www.iers.org/>

They issue leap second guidance to about 1 year in the future. They adjust
typically twice a year as needed (Jan 1 and July 1).

~~~
excuse-me
I like the name "International Earth Rotation Service" - I always picture some
dusty cavern with a giant brass gear wheel and a little old guy coming in with
a key every day to wind it up.

~~~
JonnieCache
Good isn't it.

It's the "service" that really makes it I think.

------
SeoxyS
I wonder what the impact is on computers. Will your server know to add another
second, or will it just lose sync and be one second off for the rest of times?

~~~
mbq
At least UNIX time is sane enough not to count this madness, so all time
differences are objective; only one timestamp value will ambiguously mean
(-1):60th and :00th second in UTC.

------
vr000m
The document:
[http://transition.fcc.gov/ib/sand/irb/weritacrnc/archives/nc...](http://transition.fcc.gov/ib/sand/irb/weritacrnc/archives/nc1893wp7a/1.doc)
tells implementers how to handle events around the leap second. There is some
discussion in the ITU-T to all together remove the leap second (but that
decision will be taken only before the next leap second).

------
mschalle
I'm guessing my iPhone alarm will break again?

------
rmc
This happens about every 1½ years. It is also the reason why posix/epoch time
is not the number of seconds since 1970.

------
DrewChambersDC
I'm as big an astronomy geek as anyone else, but this is so pointless. Why
bother wasting time and effort with this? Just let the discrepancies
accumulate and adjust 6 seconds every 10 years or so. It would save everyone a
little bit of effort, and you could make an event out of it.

~~~
Angostura
If it only happens every 10 years, software developers are likely to forget
about it. Hello a batch of crashing systems every 10 years. When it happens
every 1.5 years there's a trickle effect - only systems introduced in the last
1.5 years will have trouble and developers are more likely to remember to
factor it in.

------
philf
What's the point of this adjustment? Currently there is an offset of -34
seconds between TAI and UTC and aftwards it will be -35. Seems pretty random
to me...

------
capkutay
How often does something like this (days that last longer/shorter than 24
hours) happen?

~~~
sneak
They are always longer. The Earth's rotation is slowing.

~~~
tankenmate
Umm, actually no. On average the rotation is slowing, but sometimes there are
local speed ups.

------
27182818284
I think this announcement is a bit dated. I thought it went back into debate?

~~~
excuse-me
No it was rejected.

Although it's always possible that the USA will unilaterally ignore cheese-
eating surrender monkey time and adopt "freedom time"

~~~
sp332
It was deferred, not rejected. And France is on the same side of the issue as
the USA (they don't like leap seconds).

~~~
derrida
Interesting to note that China has something like "freedom time". If you are
in the west of the country, the sun rises at 9am and sets around 9pm, when in
the east it rises at 6am and sets at 6pm. The entire country is on one time,
Beijing Time, despite it stretching 3 time zones & Beijing being close to the
eastern extremity.

------
cdooh
It's only one second, while quite interesting I don't see why this matters

~~~
excuse-me
You mean why it matters that we have leap seconds (it doesn't and they should
be abolished) or why the news of it matters (because a 1000 crappy time
implementations are going to walk off the end of buffers and do weird things)
?

~~~
cdooh
Why it matters that we have leap seconds. It is just one second and it happens
randomly based on several factors

~~~
excuse-me
Really it doesn't - people just have this attachment to days and the sun for
telling the time.

The only people that a leap second realistically affects are astronomers and
they are more than capable of managing their own time software.

At roughly 1 second every 1.5 - 2 years it will be a couple of millenia before
the sun even gets an hour away from local noon - and people manage with
daylight savings time. So every 2000years we might need to introduce a leap
hour.

~~~
mjn
It's even worse than that, because solar noon is _already_ different from
local noon almost always, almost everywhere.

First, you have to be precisely in the middle of a timezone, and not one of
those weird timezones that doesn't actually follow the lines of longitude,
either. Otherwise you're skewed late or early relative to solar time.
Secondly, solar noon even at the precise center of timezones is only local
12:00 _on average_ , because the timing of solar noon vis-a-vis a 24-hour
clock fluctuates through the year by up to 18 minutes. Two factors are
involved: the Earth's orbit is slightly eccentric, and Earth's axis of
rotation isn't precisely perpendicular to the plane of its orbit
(<http://en.wikipedia.org/wiki/Equation_of_time> has details and a graph).

So all the leap seconds do is keep the _average_ local noon, at precise
centers of timezones, equal to solar noon.

------
FootballMuse
Should I get more sleep, or should I wake up earlier? decisions decisions....

------
mck-
Time is relative.

------
RedwoodCity
I look forward to the extra second of sleep.

------
michaelochurch
I can't see the point of having leap seconds, and here's why: we already
tolerate so much (intrinsic) inexactness in the relationship between solar
noon and clock noon (ignoring daylight saving time, which I actually like even
knowing that it's somewhat ridiculous) that it seems silly. First, there's the
equation of time: solar noon isn't the same clock time every day anyway: it
varies by +/- about 15 minutes during the course of the year. Second, we live
in time zones set for arbitrary reasons. For example, the average solar noon
in New York is 11:55, not noon.

I could understand inserting leap seconds if there were some specific need to
have 0 longitude be at solar noon at exactly 12:00:00, but as far as I can
tell there's not. If the clock drifts off solar noon by a half-second per year
or so, then maybe in a few millennia London will decide to use UTC-1. I could
be wrong about this, but I don't see this as a big deal.

~~~
IsTom
Astronomers and physicists care a lot about this and they are the people
running the clocks.

------
bporter
I plan on using the extra second to read more Hacker News blog posts!

------
molmalo
Nice! One more second before my next birthday! Oh, I've lost a few more
writing this... Cant we add an hour or so, so I can take a nap?

