[time-nuts] Leap Quirks

[James Cloos]

>>>>> "Warner" == M Warner Losh <imp at bsdimp.com> writes:

Jim> By which sequence?

Warner> The sequence where midnight % 86400 isn't 0.

MY appologies, but that isn't narrowing it for me.  POSIX only cares
about POSIX midnight, not UTC midnight, so the fact that it was already
past PODIX midnight when the leap second and UTC midnight happened is
irrelevant to POSIX.

Warner> Also, you need to run a hacked ntpd, because the ntp time stamps
Warner> follow the posix mandate, not the TAI-like second count...

Huh?  rfc1305 says 32.32 bit fixed point seconds since 1900-01-01
00:00:00, and of course there is the newer 64.64 bit fixed point.

The only question, then, is whether ntp and UTC agree on just when
1900-01-01T00:00:00 was. ;^)

Warner> how do programs that run for years get updated leap second
Warner> information so they continue to produce the correct times?  I've
Warner> never understood how that part of the 'right' files works...

That is libc-dependent.  I've not looked at the src in a while (many
months), but IIRC glibc opens the file every time it needs it, so it
will see a new zoneinfo database as soon as they are written to the
filesystem.

Other libcs might do things differently.  As an example, I don't think
klibc uses the zoneinfo files at all; dietlibc and uclibc may not
either.  And obviously the BSDs' libcs handle things quite differently
than glibc.  (GNU on BSD kernels is not uncommon; I'm sure I've read
about people doing one of the BSD userlands on a linux kernel, too.)
But at least for glibc it just works.

And, of course, said zoneinfo updates are needed anyway every time the
politicians muck with the timezones.  Libc also has to deal with changes
to the TZ environmental variable.  Another reason to re-read the
zoneinfo files as necessary.  (It is possible that glibc only reopens if
the stat(2) data changes; again, it has been a *long* time since I last
read that part of the glibc src.)

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6