At 23:34 04/05/06 +1000, Brett Watson wrote:
My brain hurts from trying to figure out where the status quo lies, but my
best estimate is that time_t counts in 86400-second days, with zero
corresponding to the epoch date mentioned above. Thus it is neither properly
UTC nor UT1 (it has a UTC epoch and UT1 seconds). The functions which convert
time_t values to "struct tm" (as used by mktime) know this, of course, and a
consequence of this is that no time_t conversion ever results in a leap
second date.
Although I never examined this as carefully myself as you did, I was in
the past looking into the same issue, and came up with pretty much the
same result. The easiest way to describe this, in lay terms, is that
the OS assumes there are no such things as leap seconds, and deals with
leap seconds in the same way as it does with other clock adjustments:
"Oh, I'm one second late? Let me adjust my clock to be on time again."
If you computer is connected to some NTP server, that happens automatically.
When you know about the next leap second, please tell us, we might all
be able to watch :-).
Realistically, we may have to say that timestamps may be derived from
either a
UTC or UT1 time-base (or some forsaken hybrid of the two, which seems to be
the status quo), noting that this means implementations should cope with a
value of "60" in the seconds position (and deal with it properly, or by
conversion to an adjacent non-leap second, as convenient). Times can't be
relied on to be accurate to more than a couple of seconds because of this,
but in actual practice many mail clients have clocks with far greater loss of
synchronisation than that, so the date shouldn't be considered "reliable" in
any sense at all.
And then to that add network delays,...
Regards, Martin.