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 [EMAIL PROTECTED]