[LEAPSECS] operational time -- What's in a name?

[M. Warner Losh]

In message: <6362.1206729872 at critter.freebsd.dk>
            "Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:

: In message <20080328183718.GA19897 at cox.net>, Greg Hennessy writes:

: 

: >My claim is that if POSIX defines time_t % 86400 == 0 as being

: >midnight than POSIX doesn't reflect reality, [...]

: 

: Well, POSIX clearly doesn't match the scientific definition of

: UTC, but as which of the two is more "real" is mostly a matter of

: philosophy I think.


Well, time_t is UTC, which two unfortunate problems.  The first one is
that it does pander to folks who think that the start of the UTC day
is a time_t % 86400 == 0.  The second isn't so odd for this crowd,
where the notion of a variable radix notation is accepted without
question: time_t is a variable radix that assigns the same value to
the leap second as it does to the first second in the day.  This
ambiguity means that naive math works.  It also means that if you have
a table of leap seconds, you can compute the number of 'pps pulses'
between to events, unless one of those events happens right at the
leap second.  The down side also is that it isn't possible to
construct a time_t that will print:
	2006-12-31 23:59:60
when handed to the other time functions.  In fact, the other time
functions are defined such that one cannot get the above even if one
were to fill out the struct tm correctly because the standard mandates
normalization of the struct tm before it prints things (so one can
trivially add 100s to the current just by doing foo.tm_sec += 100.

I'm not sure that the collapsing of the first second of the next day
and the leap second, when they happen, is really any weirder than
having a counter that sometimes counts to 60, but usually resets to 00
after 59.  Either the special case is that sometimes we count one
more, or the special case is that we use the same label to describe
two different seconds.  Either way, it is a pita for the software
developer...

Warner