In message: <[EMAIL PROTECTED]>
"Bill Hawkins" <[EMAIL PROTECTED]> writes:
: Um, would you care to point out the more serious bugs?
(1) Leap seconds can happen at the end of any month, not just
june/decemeber.
(2) Leap seconds can be both positive and negative
(3) Local time is typically done seprately from kernel time keeping.
(4) Kernel time keeping is usually done at the 1-10ms level, not the
1s level.
(5) Likewise, daylight savings time is usually done outside of the
kernel.
(6) It doesn't deal with sleeping processes or other kernel timeouts.
(usually == usually on unix machines)
#1 and #2 are fatal. The others reflect ignorance. #6 may cause
problems.
However, it does prove the point that leap seconds are hard.
It also doesn't really address the issue of the post you were
responding to, which is the conversion of solar time to standard time.
It doesn't deal with how many seconds there are between Dec 31, 1998
23:45:00 and Jan 2, 1999 00:15:00. It doesn't deal with converting
the time signals (which are in UTC) to a timescale without leap
seconds (not all time signal have enough information to get this: cf
IRIG). It doesn't deal with computing the variance in the 'idealized'
solar time from the 'actual' solar time based on the general slowing
of earth's rotation. It doesn't deal with the other issues that have
been done to death in the this thread.
Warner
_______________________________________________
time-nuts mailing list
time-nuts@febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
