Re: OT: Re: Less is more

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