[LEAPSECS] (no subject)

[M. Warner Losh]

In message: <alpine.LSU.2.00.0812221354000.9904 at hermes-1.csi.cam.ac.uk>
            Tony Finch <dot at dotat.at> writes:

: On Mon, 22 Dec 2008, Peter Vince wrote:

: >

: > I am trying to clarify in my mind a couple of proposals, one of which is

: > having no more leap-seconds in the civil (broadcast) time scale.  I'm

: > sorry, I must have missed your messages where you said that a lot of

: > software would fail in that scenario - could you briefly clarify please?

: 

: This isn't really about broadcast timescales, but about the semantics of

: POSIX time_t. Steve proposes to provide a well-defined uniform timescale

: on Unix systems by redefining time_t to follow some linear atomic

: timescale instead of UTC, and that the zoneinfo/tzcode library would be

: used to translate from this new version of time_t to UTC, using a leap

: second table alongside the existing time zone tables.

: 

: The code to implement this has in fact already been written, 15 or more

: years ago, but no-one uses it because it breaks too much stuff. For

: example, there is a lot of time-handling code in the kernel, and because

: it does not link with the tzcode library the proposed architecture doesn't

: accommodate its requirements. There's also a lot of code which doesn't use

: the C tzcode for time handling, such as the Java runtime. There is a

: pervasive assumption in Unix that midnight UT is when t % 86400 == 0.


This has been called the 'naive math' problem.  Applications don't
fill out struct tm's to compute time_t's.  If they all did, time_t's
definitions wouldn't matter so much.  However, many of them *KNOW*
that it *IS* seconds since 1970 (with leap seconds swizzled in, so you
can ignore them entirely).  So the time_t for Feb 15, 2008 1:23:34 is computed
like so:

     time_t t = ((2008 - 1970) * 365 + 9) * 86400 + 1 * 3600 + 23 * 60
	     + 34;

Which is broken with the above software: it is off by the number of
leap seconds.

There's another problem.  NFS requires UTC time stamps (the
unredefined time_t values), so you have to know about leap seconds,
and when they all happened to get the times right.  Again, you could
say "who cares" but lots of people do care about pedantic correctness,
so you get bugs when things aren't exactly right.  These conversions
need to happen an all file accesses, so that can have a big negative
performance effect, since rather than just copying 4 bytes, you have
to do a table lookup (at beast O(ln(#leapseconds)).  There's no way to
compute leap seconds in the kernel without it.

Warner