Leap second tonight

Just a reminder that there's a leap second tonight.

Last time I watched for what happened on 01/01/2006, there was a little bit of chaos: http://markmail.org/message/cpoj3jw5onzhhjkr?q="kevin+day"+leap+second+reminder+nanog&page=1&refer=cnkxb3iv7sls5axu

I've been told that some of the causes of these problems are fixed on any reasonably recent ntp distribution, but just in case, you might wanna keep an eye out if you're seeing any weirdness. The worst damage I'd heard from anyone after that event was their clock being significantly off for several hours.

-- Kevin

Since leap seconds apply to UTC, won't the leap second be in about 22 minutes?

-jasper

One note, if you're using ntpd along with an HF receiver and the
CHU reference driver, you'll either need to manually retune your receiver
to 7850 kHz or update your ntpd.

  As of approximately one hour ago, CHU has moved from 7335 kHz,
where it has been for several decades up to 7850 kHz due to increasing
shortwave broadcast interference.

  Also note that many reference clocks, including GPS derived ones,
do not handle leap seconds correctly, so it may be a while before your
reference clocks stabilize.

  Happy New Year!

  --msa

It looks like clepsydra hasn't been updated:

     address ref clock st when poll reach delay offset disp
-~192.5.41.40 .USNO. 1 194 1024 377 41.1 5.19 38.2
-~130.207.244.240 .GPS. 1 68 1024 377 23.1 11.09 1.3
~127.127.7.1 127.127.7.1 7 53 64 377 0.0 0.00 0.0
+~198.60.22.240 .GPS. 1 436 1024 377 65.7 7.09 32.5
~204.123.2.5 .GPS. 1 182 1024 377 80.4 1011.4 24.9
+~67.128.71.76 .CDMA. 1 178 1024 377 16.8 10.85 79.2
+~18.26.4.105 .CDMA. 1 562 1024 377 8.4 7.90 235.8
-~209.81.9.7 .GPS. 1 170 1024 177 79.9 16.96 170.8
*~209.51.161.238 .CDMA. 1 1019 1024 377 3.9 10.13 2.5
-~204.152.184.72 .GPS. 1 697 1024 377 75.0 1.81 3.2
+~18.145.0.30 .PSC. 1 1737 1024 376 10.0 8.52 297.1

Quick, someone call DEC.

Seriously, clepsydra is one of the older ntp servers out there, and hasn't dealt with the leap second correctly.

A report from a DHCP/DNS appliance vendor here:

This begs the question - how the heck do timekeepers and politicians get
away with last minute time changes?

Surely there's -some- pushback from technology related interest groups to
try and get more than four weeks warning? :slight_smile:

Adrian

Adrian Chadd wrote:

This begs the question - how the heck do timekeepers and politicians get
away with last minute time changes?

Surely there's -some- pushback from technology related interest groups to
try and get more than four weeks warning? :slight_smile:

?

Notice for the leap second was issued on July 4 2008.

http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.36

Nick

Try six months. NTP itself sets the leap indicator by 28
days prior to the leap and clears it before the end of the following day,
so in theory the appliance itself had at least 4 weeks notice and the rest
of us had an additional five months.

  IERS announces a pending leap second six months in advance. The
announcement for this one was dated July 4th.

  System vendors have only had 37 years since the first leap second
to figure this out; please be patient.

  However, I can't excuse them for bugs surrounding the final day
of a leap year. The Julian calendar is not exactly a new phenomenon.

  --msa

Wow, how'd I miss that, I wonder? :slight_smile:

I'm just angry at the jack moves pulled by last minute timezone changes
back in Australia, and the massively stupid repercussions seen throughout
chunks of IT (incl. network auditing setups I had to poke at the time.)

I'll add "handling second == 60" to the list of things I should check
for in my code. Thanks. :slight_smile:

Adrian

Adrian Chadd wrote:

This begs the question - how the heck do timekeepers and politicians get
away with last minute time changes?

Surely there's -some- pushback from technology related interest groups to
try and get more than four weeks warning? :slight_smile:

Adrian

....

The first notice I found was dated July 4th 2008

http://tycho.usno.navy.mil/bulletinc2008.html

Adrian Chadd wrote:

Wow, how'd I miss that, I wonder? :slight_smile:

I would recommend lodging a complaint to the relevant authorities. That's
sure to help.

But seriously. Leap seconds occur every couple of years, either on July
30th and Dec 31. Sometimes both. And sometimes every consecutive year for
a couple of years on the run.

If your code insists on exactly 60 seconds in all minutes, or 86400 seconds
in a hour, your code is wrong. You need to take this into account, because
leap seconds are actually pretty common occurrences.

I'm just angry at the jack moves pulled by last minute timezone changes
back in Australia, and the massively stupid repercussions seen throughout
chunks of IT (incl. network auditing setups I had to poke at the time.)

I'll add "handling second == 60" to the list of things I should check
for in my code. Thanks. :slight_smile:

Yeah, last minute declarations are annoying. Like the british government's
mad-cap idea to change VAT for the first time in donkey's years from 17.5%
to 15% with 7 days warning. Now that's screwed up.

Nick

This begs the question - how the heck do timekeepers and politicians get
away with last minute time changes?

Surely there's -some- pushback from technology related interest groups to
try and get more than four weeks warning? :slight_smile:

Having been involved in the leap second business, I can tell you that Daniel
Gambis strictly follows the rules, which are
Bulletin C is mailed every six months, either to announce a time step in UTC or to confirm that there will be no time step at the next possible date.
If you want more lead time warning, pay attention to the LOD graph in

http://hpiers.obspm.fr/eop-pc/

The long term LOD offset is about 1 msec now. That means that every day, Earth time and atomic time will drift off by 1 msec. Since there
are 1000 msec in the second, and since the rule is that a leap second is chosen when the difference (UT1−UTC) approaches 0.9 seconds, projected
out to the next period, and since the strong preference is to have leap seconds in January, you can generally figure out what will happen before
Daniel announces it.

For example, in one year the offset should be ~ 400 msec, so I will informally predict another leap second in January, 2011, not 2010.
Keep watching that graph.

Anyone who is dealing with Leap Second code should keep in mind that negative leap seconds (i.e., no second # 59, instead of an extra second called
60) are a distinct possibility. It all depends on the "weather" at the core mantle boundary - note that the LOD offset was almost 3 msec not too long ago.

Regards
Marshall

[...]

But seriously. Leap seconds occur every couple of years, either on July
30th and Dec 31. Sometimes both. And sometimes every consecutive year for
a couple of years on the run.

It's theoretically possible for leap seconds to be introduced at the end of
March and September. It's never happened but it might, so I suppose software
should allow for the possibility.

Regards,

Leo

It's theoretically possible for leap seconds to be introduced
at the end of March and September.

As I recall, NTP supports leap seconds every month,
for which there is a prediction that even this
would be insufficient at some point in this
millennium (depending, of course, on the actual
rotation speed). There have been on again/off again
talks to abolish the leap second for quite a number
of years.

Gary

I've gleened from this thread that:

     * everyone uses UTC, or should, because UTC is a uniform time scale,
       except for those leap seconds
     * UTC is sourced from the frequence of a radio emission from cesium
       atoms which are extremely constant
     * UTC can get out of whack with the rotation of the earth around the
       sun, because our rotation is not uniform, but is calculated rather
       than measured (well, sort of)
     * UTC is TAI plus leap seconds. In 1972, when leap seconds were first
       introduced, UTC was TAI - 10 seconds. UTC is now TAI - 34 seconds.
       TAI ticks exactly as fast as UTC, ignoring leap second adjustments.
     * UTC is slower than UT1 by about 1ms per day.
     * On 12/31/2008 UTC was (-) 591.8ms behind UT1. On 1/1/2008 UTC was
       407.1ms ahead of UT1.
     * Leap seconds are applied to UTC every few years to remain in line
       with UT1, the time based on the rotation of the earth around the sun.
     * GMT is used to imply UT1, but sometimes UTC, but really GMT is just
       massively confusing and you shouldn't use it, either in conversation
       or in your servers/routers, because nobody is really sure without
       reading a lot of documentation what GMT means for each
       manufacturer/OS/software.
     * When writing code regarding dates and times, know that any year may
       have 366 days, and any minute may have 61 seconds.
     * When in doubt, Dr. Daniel Gambis is always right.

Beckman

I've gleened from this thread that:

     * everyone uses UTC, or should, because UTC is a uniform time scale,
       except for those leap seconds

Local time is totally appropriate in some circumstances, but it
is pretty much always defined as just an offset to UTC. UT1 is
important when you are doing astronomical observations or depend
on such things.

     * UTC is sourced from the frequence of a radio emission from cesium
       atoms which are extremely constant

There is nothing too special about cesium. It's properties and
the properties of the particular transition are convenient from
an engineering standpoint.

     * UTC can get out of whack with the rotation of the earth around the
       sun, because our rotation is not uniform, but is calculated rather
       than measured (well, sort of)

No its not about years, that's what February 29th is for, it's about
days. As the Earth rotates (there's a "rotation" versus "revolution"
nomenclature), the sun appears to move around it daily. This is the
solar day. At a certain point, at a certain location, the sun is
at the highest it will be in the sky for that rotation. This is solar
noon. The time between two consecutive noons at any location is not
constant mostly due to the Earth's orbit being elliptical and the tilt
of the Earth's axis. But for any place on Earth, the mean solar day,
the average of the solar day over the year, is the same.

If the Earth was a solid sphere rotating at a constant speed, that
would be the end of the story. But it's not and for a variety of
reasons, the rotation of the Earth changes with time (mostly slows).
This causes the mean solar day to get longer.

     * UTC is TAI plus leap seconds. In 1972, when leap seconds were first
       introduced, UTC was TAI - 10 seconds. UTC is now TAI - 34 seconds.
       TAI ticks exactly as fast as UTC, ignoring leap second adjustments.
     * UTC is slower than UT1 by about 1ms per day.

That's a very tricky sentence. I think that the mean solar day right
now is about 86400.002 s long. The mean solar day was actually exactly
86400 s long sometime around 1820.

     * On 12/31/2008 UTC was (-) 591.8ms behind UT1. On 1/1/2008 UTC was
       407.1ms ahead of UT1.
     * Leap seconds are applied to UTC every few years to remain in line
       with UT1, the time based on the rotation of the earth around the sun.

A time based on the rotation of the Earth.(period) As mentioned
above, it doesn't really have anything directly to do with Earth's
location in its orbit.

     * GMT is used to imply UT1, but sometimes UTC, but really GMT is just
       massively confusing and you shouldn't use it, either in conversation
       or in your servers/routers, because nobody is really sure without
       reading a lot of documentation what GMT means for each
       manufacturer/OS/software.
     * When writing code regarding dates and times, know that any year may
       have 366 days, and any minute may have 61 seconds.

Also remember that an administrator or automated clock recalibration
may take you forward or back in time any arbitrary amount.

     * When in doubt, Dr. Daniel Gambis is always right.

Very, very few should not defer to his judgement on such matters.

Peter Beckman wrote:

    * GMT is used to imply UT1, but sometimes UTC, but really GMT is just
      massively confusing and you shouldn't use it, either in conversation
      or in your servers/routers, because nobody is really sure without
      reading a lot of documentation what GMT means for each
      manufacturer/OS/software.

WET/WEST is a little more precise and less confusing than GMT/BST (or IST if you're of a more celtic nature, although this confuses people living on the Indian subcontinent) although in tz-land, GMT has a specific and pretty consistent definition. But it is generally a bad idea to use it. People get confused.

    * When writing code regarding dates and times, know that any year may
      have 366 days, and any minute may have 61 seconds.

Or 59 seconds in the case of a negative leap second.

Nick

   * UTC can get out of whack with the rotation of the earth around the
     sun, because our rotation is not uniform, but is calculated rather
     than measured (well, sort of)

  As Crist Clark points out, leap seconds are about the Earth's
rotation about its own axis, not its revolution (orbit) around the
sun. Atomic clocks are much more consistent and uniform than the
Earth's rotation. If we don't correct for the differences somehow,
eventually wall clock time would get out of sync with the day/night
cycle. In $LARGE_NUMBER years, 1:00 PM would be in the middle of the
night.

  Earth's orbit and the Julian calendar have the same problem, which
is why we have leap days. Otherwise, the calendar would get out of
sync with the seasons.

   * When writing code regarding dates and times, know that any year may
     have 366 days, and any minute may have 61 seconds.

  I wouldn't even define it that narrowly. We might end up with 62 or
63 or 57 seconds in a minute, or 364 or 367 days in a year.
Internally, store everything using a fixed-unit offset (e.g.,
traditional Unix time, i.e., seconds from 1 Jan 1970). Use OS
provided facilities to translate to and from human-friendly
representations, and thus make it the OS's problem. (If the OS is
your problem... sucks to be you. You'll need lots of tables of
historic, idiosyncratic clock/calendar changes to get it right.)

  For program timers (timeouts, etc.), don't use wall clock time at
all, since the wall clock may be wrong, and the admin may fix it,
yielding time travel. Most OSes provide something like a "seconds
since boot" value, which should always monotonically increase (unless
you're running Windows 95, heh), regardless of what the admin is doing
to confuse matters.

  From the other side of the coin: As an admin, avoid advancing the
wall clock in large steps, or going backwards at all. If you must do
either, do it in single-user mode, or whatever your platform's
equivalent is. Don't assume the programmers got it right.

  Another programmer tip: When storing dates and times in a file,
database, etc., and you have to care about multiple timezones: Store
at least three of UTC, local time, calculated difference, logical
local timezone. The extra information lets one figure out
after-the-fact what the timezone tables on the system said when the
user entered the information. When the gov'mint monkeys with the time
zones, there's always a lag between official announcement and local
implementation. Without knowing what the time zone tables said, it
can be hard to know if you should apply a correction later.

-- Ben