Mark your calendars: celebrate the Leap Second!

According to Bulletin C of the International Earth Rotation Service:

A positive leap second will be introduced at the end of December 2008. The sequence of dates of the UTC second markers will be:
2008 December 31, 23h 59m 59s
2008 December 31, 23h 59m 60s
2009 January     1,   0h   0m   0s
The difference between UTC and the International Atomic Time TAI is:
from 2006 January 1, 0h UTC, to 2009 January 1 0h UTC : UTC-TAI = - 33s
from 2009 January 1, 0h UTC, until further notice           : UTC-TAI = - 34s

This means that tomorrow, 3:59:59 PM PST will be followed by 3:59:60 PM PST prior to the advent of 4:00:00 PM PST.

Tags: ,

10 Responses:

1. a_0001 says:

We who are subscribers knew about this in July.

What will you do with your second second?

2. mcity says:

Wait a second, wait a second. I thought they were only supposed to do this once every four millenia. This totally throws off my schedule! Who's in charge, I wanna talk to their manager!

3. muerte says:

So what are the unixtimes for each of those...

1230767999
1230768000
1230768001

??

So the leap second is 1230768001 then.

• jwz says:

Actually the progression will be 1230767999, 1230768000, 1230768000, 1230768001. POSIX Unix time is UTC with the explicit exception that it doesn't handle leap seconds, so there is a discontinuity when leap seconds occur. The leap second is the first of the two 1230768000 numbers.

One would hope that the struct tm that you get from localtime() or gmtime() will have tm_sec=60 at the leap second, but given an ambiguous time_t as its argument, I'm not sure how that would be possible. So I assume that it never actually hits 60.

There's also some craziness about the right/ timezones that I don't fully understand the workings of.

• bodyfour says:

right/ assumes that the system's idea of time_t is pseudo-TAI with the 1/1/1970 unix epoch remaining the same (as opposed to TAI which is defined as UTC+10s in 1972) On systems support it you get the full leap-second treatment (tm_sec==60, etc) Difficulties:

• Your system's idea of time_t will now be 23 (going on 24) seconds off from the rest of the world. Have fun synchronizing. I'd imagine there's some ntpd-guru trick to do this but I don't know what it is.
• Are you sure there's no code you run that assumes tm_sec is 0..59?
• Will every remote machine that you exchange formatted dates with deal with 23:59:60? (for example, if you're running a web server will clients cope with that in the "Date:" or "Last-Modified:" header?)
• Are you sure there's no regex's anywhere on your system that include ":[0-5]\d" or similar when parsing dates?
• Are you sure there's nothing that assumes 60-second minutes or 3600-second hours? (unsigned second_within_hour = time(NULL) % 3600;)
• Remember to update your zoneinfo files every time a new leap second is announced!

It's a can of worms which is why nobody does it. It's easier to just punt on the whole leap second question

• labelreader says:

The lack of an actual 60th second is cool for us lazy programmers, though. Just divide by 86400 to count the days without accounting for any weird fractions from leap seconds. Which I'd been blithely doing for years without thinking about it until our prototyping wizard started asking deep questions about Unix time during development of the Epoch Clock. Anyway, thank you, Epoch Time Gods.

4. muerte says:

Question... was the music you were listening to coincidence or on purpose?

• romulusnr says:

Hi, and welcome to the JWZ livejournal. Please remember to follow the commenting guidelines, and read the FAQ.

5. leopanthera says:

I submit that the "International Earth Rotation Service" is possibly the coolest thing you can ever have on your business card.

6. I was under the impression that the Earth rotated without any assistance from giant steam engines buried beneath the Earth's crust and maintained by a shadowy organisation separate from any merely human government.

Apparently I was wrong.