[time-nuts] Leap Quirks

[M. Warner Losh]

In message: <m3mye8qen3.fsf at lugabout.jhcloos.org>
            James Cloos <cloos at jhcloos.com> writes:
: >>>>> "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.

posix midnight and utc midnight are the same things.  You had said
that the system time was returned as ....24 at UTC 2009-01-01
00:00:00, which isn't posixly correct.

: 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. ;^)

ntpd needs to convert the time from the kernel to the 32.32 number.
To do that, by default it assumes a POSIXly correct time_t.  That's
the only point I was making.  If a different number is returned (one
with leap seconds added in), then ntpd has to cope.

: 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.)

Yea, I was wondering if it did a stat on every time conversion, or if
it batched them somehow.  Doing one on every conversion seems very
heavy-weight to me...  Hence my question of how do the updated
zoneinfo files happen, and how does the application get notified of
the changed of leap info in case they have already computed a time
that would be affected by the new leap information.

Warner