Windows failed to report it as well, even though SocketWatch had a nice icon telling me that a leap second would be added.

My GPS receiver failed to lock on to a time at all. :(

(Reply) (Thread)

at least one of the gps receivers repeats 00:00:00 (utc). (i'm not saying OS X does this, because i just don't know.)

see my latest post (http://www.livejournal.com/users/ch/542201.html) for what my gps receiver did.

(Reply) (Thread)

Does your GPS receiver agree with the java applet on time.gov? That site agrees with my Windows boxes and the NTP servers I use, but my Linux boxes are all one second behind. Did the leap second fail to get inserted somewhere, or did Linux do it twice, or what? It's all very maddening.

(Reply) (Parent) (Thread)

my gps rcvr and my linux boxen agree. i use several pool.ntp.org servers for my ntp peers.

i can't quite tell if they match the java applet.

(Reply) (Parent) (Thread)

I was watching the java applet on time.gov (along with my party guests) and it did not appear to acknowledge the leap second.

(Reply) (Parent) (Thread)

Hrm. My FreeBSD 4.10 box has a number of lines similar to this in /var/log/messages:
Dec 31 18:00:00 rivaridge /kernel: microuptime() went backwards (42163535.452289 -> 42163535.255679)

(Reply) (Thread)

I see the same on my FreeBSD 4 boxes, but my FreeBSD 6 box didn't have any such confusion.

(Reply) (Parent) (Thread)

Hmm, there's a lack of leap second messages on my Linux box (assuming I'm looking in the right place), but thet's probably due to a lack of ntp or similar running. The Windows box was not running at the time, but presumably it'll correct itself next time it syncs with Janet.

(Reply) (Thread)

unless you're running ntp or hooked up to some form of atomic time (gps, wwv/wwvb, etc -- which you typically do via ntp), there's no way for the kernel clock to know to insert the leap second. there could be some other mechanism, but there isn't one today.

(Reply) (Parent) (Thread)

Oooh, your icon is in colour! *steals*

(Reply) (Parent) (Thread)

POSIX specifically indicates that time_t is leap-second ignorant. This decision is widely complained about to this day, but its also somewhat understandable — it'd be somewhat gross to require libc have access to an up-to-date list of leap seconds just to handle localtime() Therefore the kernel's idea of time_t must be set after each leap second event.

Ntp does the best it can under the circumstances; basically when it detects a leap second it slews the time a bit.

Most modern UNIXes use the Olsen time library... aka "zoneinfo". This lets you get leap-second-aware time (or at least as aware as the leap-second list in the zoneinfo file happens to be current) by requesting the "right" timezone. For instance on a Fedora Core box:

$ TZ=US/Pacific date; TZ=right/US/Pacific date
Sat Dec 31 17:20:34 PST 2005
Sat Dec 31 17:20:11 PST 2005

However it seems that OS X doesn't have a /usr/share/zoneinfo/right directory, so I guess you always get the POSIX value

(Reply) (Thread)

I believe that the main reason POSIX time is defined that way is because much more software than just libc performs leap-second-ignorant calculations with it.

(Reply) (Parent) (Thread)

No, it's not that gross; having time_t count only non-leap seconds is much grosser. I wish it were possible to move towards a new API that counted atomic seconds.

(Reply) (Parent) (Thread)

I thought today seemed to drag.

(Reply) (Thread)

I'm sad to note that this is also causing a UML VM I have to experience some difficulty.

(Reply) (Thread)

Sad. Aren't they switching to Xen?

(Reply) (Parent) (Thread)

Yeah, that's something they're actively testing.

(Reply) (Parent) (Thread)

Sadly, my Linux boxes did not spit out such a message. However, the leap second was corrected by NTP during the daily run. I'm curious as to why my machines did not insert the leap second themselves, though.

Would you mind providing a little more information about one of the machines that did insert the second? Most of mine run Debian untested, kernel 2.6.12, and the current Debian ntpdate package (ntpdate 4.2.0a@1:4.2.0a+stable-8-r).

(Reply) (Thread)

"...the leap second was corrected by NTP during the daily run" -- I think that's the issue - from that I read that you're not running ntpd, just ntpdate via cron - I'm pretty sure it's ntpd that will schedule the leap second in advance.

http://www.meinberg.de/english/info/leap-second.htm seems to confirm that: "If an NTP daemon detects a leap second announcement, it passes the announcement on to its clients, and notifies its own operating system clock of the upcoming leap second, if the operating system is aware of leap seconds.".

(Reply) (Parent) (Thread)

Ah-ha! Thanks very much; I understand now. As my onboard clocks are rarely so inaccurate as to lose more than one second in 24 hours, I don't think I'll need to run a proper ntpd.

(Reply) (Parent) (Thread)

Spoken like a man who doesn't routinely use computers aged enough that clock batteries are iffy and, worse, that schedule disk hardware interrupts at the same priority has clock hardware interrupts. (No, really. Apple 68k Macs. Boggle on that.)

(Reply) (Parent) (Thread)

Fedora Core 4, Linux 2.6.14-1.1637_FC4smp #1 SMP Wed Nov 9 18:34:11 EST 2005.
ntp-4.2.0.a.20040617-8
Daemon running as: ntpd -u ntp:ntp -p /var/run/ntpd.pid -g

(Reply) (Parent) (Thread)

Why doesn't everybody use the /right/ timezones?

Just wondering.

(Reply) (Thread)