Leap Second At The End of 2005

Ruff_ilb writes "Because of the discrepency between an ephemeris second (the fraction 1/31,556,925.9747 of the tropical year for 1900 January 0 at 12 hours ephemeris time) and the second of atomic time (the duration of 9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the cesium 133 atom), we're left with more than leap years. In order to ensure that the the atomic time and civil stay coordinated, "Civil time is occasionally adjusted by one second increments to ensure that the difference between a uniform time scale defined by atomic clocks does not differ from the Earth's rotational time by more than 0.9 seconds."" And Happy New Years everyone ;)

Re:How did you use yours?

[Extrudedaluminiu]

Do any NTP servers keep track of these seconds?

The clock problems

[Antony-Kyre]

Did anyone notice the atomic clock problems that happened when the leap second occurred? Some atomic clocks were different than others. If I am not mistaken, and I don't believe I am, the leap second occurred at 23:59:60 UTC (yes, I typed that in correctly). I also flipped back and forth between like ABC and NBC, Pacific Time, and notice they were like 3 seconds or so different in their countdown clocks. What is up with that?

Re:Highlights problem with ntp...

[Dr. Zowie]

Hmmm... Maybe I wasn't clear to start with. If (using my handy atomic clock) I made an NTP timestamp at precisely 11:00 pm UTC yesterday, and another NTP timestamp at precisely 11:00 pm UTC today, those two timestamps would differ by exactly 24 hours, although the two UTC times are 24 hours and one second apart. That is an error. T

he error is carried by the fact that NTP stays synchronized to UTC in the present, but the past is "free floating". If, today, I convert my previous NTP timestamp back to UTC I will find that it occurred at 11:00:01pm yesterday rather than 11:00:00, the time that I actually made it. That's because NTP counts offsets from the present moment, assuming that UTC behaves like TAI.

tsunami caused rotation change

[zontroll]

Are they also adjusting the clock because the Dec 2004 earthquake and tsunami caused a small change in the rotation speed of the earth? I believe it caused the rotation to last a few miliseconds longer for that day. There some info at the NOVA site on pbs.org:
http://www.pbs.org/wgbh/nova/tsunami/ask-050331.ht ml [pbs.org]
(scroll down to the sixth question)

Log of Atomic GPS Clock adjustment

[BiggRanger]

I did up a project on sourceforge.net a few years back to sync my computers with a GPS http://atomicgpsclock.sourceforge.net/ [sourceforge.net]. Below is a log of the activity, normally there is a +/- 0.016 or so second instability, but 18:59:59 EST (or 23:59:59 UTC) the Navy made a 1 second adjustment to the GPS system, and it's vibible in the log at the next scheduled sync (in bold)

2005.12.31 18:33:49 00032 GPS Status - Tracking: 3D
2005.12.31 18:43:27 00020 Offset: 000.016 Buffer: 13
2005.12.31 18:43:27 00032 GPS Status - Tracking: 3D
2005.12.31 18:43:49 00020 Offset: -000.031 Buffer: 13
2005.12.31 18:43:49 00032 GPS Status - Tracking: 3D
2005.12.31 18:45:15 00033 GPS Status - Tracking: No
2005.12.31 18:45:34 00032 GPS Status - Tracking: 1D
2005.12.31 18:46:48 00033 GPS Status - Tracking: No
2005.12.31 18:46:52 00032 GPS Status - Tracking: 3D
2005.12.31 19:01:43 00033 GPS Status - Tracking: No
2005.12.31 19:01:55 00032 GPS Status - Tracking: 1D
2005.12.31 19:03:45 00020 Offset: 001.016 Buffer: 13
2005.12.31 19:03:45 00032 GPS Status - Tracking: 2D
2005.12.31 19:13:45 00020 Offset: -000.016 Buffer: 13
2005.12.31 19:13:45 00032 GPS Status - Tracking: 3D
2005.12.31 19:23:43 00020 Offset: 000.000 Buffer: 13
2005.12.31 19:23:43 00032 GPS Status - Tracking: 3D
2005.12.31 19:33:43 00020 Offset: 000.000 Buffer: 13
2005.12.31 19:33:43 00032 GPS Status - Tracking: 3D
2005.12.31 19:43:30 00033 GPS Status - Tracking: No
2005.12.31 19:43:40 00032 GPS Status - Tracking: 1D
2005.12.31 19:53:41 00020 Offset: -000.031 Buffer: 13
2005.12.31 19:53:41 00032 GPS Status - Tracking: 3D
2005.12.31 20:03:39 00020 Offset: 000.000 Buffer: 13
2005.12.31 20:03:39 00032 GPS Status - Tracking: 3D

last year the US proposed to cancel this update

[Herve5]

I know a person in charge of geostationary satellite control, and she says this time adjustment will have imposed a large amount of satellite and ground station software updates.
She added that because of this among many other updates, there have been a formal proposal by the US, some months ago, to change the rules and abandon any updating before there is a full day (!) of delay, but the proposal was refused.

FYI, this 1-s correction is the first in 5 years, but there were 4 others in the previous 5 years.

Waiting for one day would basically mean renouncing for some thousand years, or more probably, waiting for the next civilization to come :-)

Hervé

WWV

[spaceyhackerlady]

>blockquote> I watched the time at Time.gov: 23:59:56 (UTC) =>23:59:57=>23:59:58=>23:59:59=>23:59:60!=>00:00:0 0 It was Amazing! This was the first time for me... *remebers where I was at that moment

I listened to it on WWV. They drop the 29th and 59th tick of each minute, and at 2359 UTC it sounded like (I counted the seconds myself):

tick (57)
tick (58)
silent (59, as usual)
silent (60, leap second)
BEEP (0000 UTC 1 January 2006)
titick
titick
titick
tick
tick

...and so on. The UT1 time correction went from -0.6 to +0.3 seconds. It's encoded in the double ticks.

Yes, I got a recording. Lame or what?

...laura

Re:Highlights problem with ntp...

[Floody]

The NTP protocol that all of us cool kids use to synchronize our computers' clocks has a fundamental flaw -- the NTP time is tied to UTC, but contains no leap seconds at all, more like TAI, the atomic time standard. When there's a leap second, the system's solution is to ignore it.

So, as of today, any time stamp you have made using NTP, ever, has been retroactively displaced by one second. Intervals that included midnight (UTC) last night are all too short by one second.

This may not be a problem for handling your calendar appointments, but it can muck up all kinds of scientific applications that require high precision.

You are confusing transport with content. NTP, by itself, has no inherent concept of leap-seconds, leap-years or any other sort of temporal leapage; it simply provides a way to statistically analyze time sources, account for latency, jitter and dispersion and keep a local clock as closely synced as possible to one or more remote clocks. When making adjustments to the local clock, it is careful to not introduce large amounts of skew which might wreak havoc on time sensitive running processes Iinstead it will slowly "bump" the clock towards what it currently thinks is the most accurate time.

To make NTP useful, of course, it must be provided with one or more ultimately trusted authoritative time source (these can be stratified [stratums] in terms of network closeness to the original time reference). As you noted, major reference clocks on the net use a UTC time source, which makes more sense for common applications than TAI, as non-scientific-clocks world-wide are based on UTC.

When the leap second was added at the beginning of this year (this morning -- or perhaps the very end of last year), the UTC was simply adjusted by one second. stratum 1 NTP servers which are directly hardwired to reference clocks (ultimately, that means atomic clocks), adjusted by the UTC-TAI offset, trust their reference clocks above all else; thus when they saw the UTC adjustment they simply assumed that their local cpu clock was off and began adjusting it accordingly (from the reference frame of the NTP timescale, time "stood still" for one second). Simultanously, any new broadcasts or query-responses sent out on a network interface used the newly offset time. Downstream NTP daemons would make a similar conclusion; that their local clock had drifted one second off and should be slowly adjusted towards the correct time.

The net effect is that if you were to view NTP as a continous set of incrementing ticks beginning on 0h Jan 1, 1900 GMT (UTC origin is TAI -10s 0h Jan 1, 1972, and thus technically is meaningless for timescales that originate prior to the epoch), historical timecodes are effectively lost on each update where a leap second has been inserted, however the current timecode is in sync with UTC.

Sensitive scientific applications will likely simply avoid the UTC offset completely and use a direct TAI reference clock.

Re:Highlights problem with ntp...

[Jaseoldboss]

According to the FAQ on the NTP homepage [ntp.org] "NTP uses UTC as reference time"

Further down there is a discussion of how leap seconds are handled. I was curious so I checked my computer clock (which is synced using NTP) against my alarm clock (which uses the radio signal from the MSF [npl.co.uk] service and they are the same. So it seems that NTP must have observed leap seconds contrary to your original post.

Re:The hard way

[supersat]

You might be joking, but the US actually does want to abolish leap seconds [bbc.co.uk]. As a compromise to keep UTC somewhat in sync with UT1 (time as measured by astronomical observations), a leap hour [cam.ac.uk] would be inserted every 500-700 years.

I wish I were making this up.