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