NTP and POSIX Time in conflict?
D. J. Bernstein
djb at cr.yp.to
Thu Dec 7 08:22:46 UTC 2000
Some operating systems use local time as their basic clock. Novice
programmers often tell me that this is a good thing. I always find it
amusing to compare their arguments to the anti-leap-second arguments:
Clocks are local time Clocks are non-leap-second counters
--------------------------------------------------------------------
Computer clocks are set by Computer clocks are set by
humans, who use local time. NTP, which counts non-leap seconds.
I don't know the time zone. I don't know the UTC-TAI difference.
Who cares about occasional Who cares about occasional
errors in time subtraction? errors in time subtraction?
Governments change time zones. IERS changes the leap-second table.
Keeping up to date is painful. Keeping up to date is painful.
I just signed a contract that I just signed a contract that
specifies a future local time. specifies a future time in UTC.
How do I represent that time? How do I represent that time?
An isolated system can't learn An isolated system can't learn
about time-zone changes. about new leap seconds.
The unfortunate reality is that an isolated system can't maintain an
accurate local-time clock. How do we react to this? Do we screw up the
semantics of localtime(), saying that it's just fine for localtime() to
ignore changes in time zones and in the leap-second table? Or do we
maintain our standards for the semantics of localtime(), and acknowledge
that isolated systems can't support it properly?
---Dan
More information about the tz
mailing list