On 7-mei-04, at 5:24, Martin Duerst 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).
UTC epoch???
The problem with today's use of time in many systems is that they
assume a day has 86400 seconds. Unfortunately, this isn't true for the
most used definitions of "second" and "day". Even more unfortunate,
moving away from the scientific definition of the second makes accurate
synchronization impossible, and moving away from the common
understanding of what a day is breaks the principle of least
astonishment and may lead to legal problems (people disagreeing whether
something happened before or after a certain deadline).
I believe any system that uses a Unix-like timestamp system is on the
road to trouble. I think it makes sense to define a mailng date format
such that it isn't impacted by this trouble. Since we don't need very
exact time information for mail, it would appear that this should be
trivial, but I do think we need relatively accurate date information
for mail. One or two seconds shouldn't be a huge problem, but TAI vs
UTC is 32 seconds already.
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.
I'm sure this is the way many systems implement NTP. However, a better
way to do it is to take the NTP information and use it to callibrate
the internal clock. This means that after some time, the internal clock
becomes very reliable, and full second adjustments shouldn't happen.
(NTP has two bits that indicate impending leap seconds, by the way.)
When you know about the next leap second, please tell us, we might all
be able to watch :-).
Not any time soon: http://hpiers.obspm.fr/eoppc/bul/bulc/bulletinc.dat