On Sun, 1 Jan 2006, David Malone wrote:
> I didn't have the facilities to record any phase information. I did
> try recording BBC Radio 4, but they transmitted Big Ben rather than
> pips ;-(
Having found that problem with Radio 4 last leap second, I tried BBC World
Service this time (having tested the night before that they broadcast the
pips at midnight) but they also broadcast Big Ben for the New Year. Where
does broadcast the pips at the New Year?
The Linux kernel (with NTP synchronisation) duly syslogged
Dec 31 23:59:59 digraph kernel: Clock: inserting leap second 23:59:60 UTC
and Markus's program showed a transition from 1136073600.005623 to
1136073599.013130, i.e. 23:59:59 was repeated (whereas a POSIX clock in
perfect synchronisation with UTC should appear to repeat 00:00:00, and a
kernel source code comment
/* The timer interpolator will make time change gradually instead
* of an immediate jump by one second.
*/
describes what would practically be a safer approach, if the code followed
the comment).
I tried polling the plain text (not Java) clock on www.time.gov (via lynx
-dump
http://www.time.gov/timezone.cgi?UTC/s/0 | head -5), but around the
time of the leap second that seemed heavily overloaded and taking much
longer than a second to return results. However I alternated the results
from that clock with local clock timestamps (which as above had had the
leap second inserted by repeating 23:59:59), and a result from
www.time.gov of
Right now, the official U.S. time is:
00:00:05
Sunday, January 1, 2006
was immediately followed by a local timestamp of "Sun Jan 1 00:00:04 UTC
2006", suggesting that the www.time.gov text clock had not inserted the
leap second at that point (or it has rounded the time to the next rather
than the previous second boundary). I didn't think to log the HTTP header
timestamps as well as the timestamp in the page text.
--
Joseph S. Myers
jsm_at_polyomino.org.uk
Received on Sun Jan 01 2006 - 10:56:33 PST