Steve Allen scripsit:
> Yet the zoneinfo needs to be updated numerous times per year at
> unpredictable intervals as a result of arbitrary actions by
> legislatures all over the world.
Indeed, but the user has a substantial incentive to update to the latest
data if directly affected by the change: the computer's clock will be
wrong by an hour. The pressure to update to the latest leap-second table
is far less.
> The additional data required to handle leap seconds in the "right"
> versions of zoneinfo is trivially smaller than the geopolitical data,
> and the scheduling is more predictable.
Granted.
> If POSIX were to fix the definitions of time_t and epoch, why would
> this not imply that handling leap seconds with Unix would become
> trivial?
Because there is far too much code that believes, for example, that if
you add 86400 to a time_t representing 2005-12-31T00:00UTC, you get a
time_t representing 2006-01-31T00:00UTC. Or that if you have a
time difference in seconds, you can divide by 3600 and get one represented
in hours.
The upside of Posix is that time arithmetic is simple. The downside is
that Posix sometimes lies about elapsed time and labels both a leap second
and the preceding second with the same time_t.
--
Newbies always ask: John Cowan
"Elements or attributes? http://www.ccil.org/~cowan
Which will serve me best?" http://www.reutershealth.com
Those who know roar like lions; jcowan_at_reutershealth.com
Wise hackers smile like tigers. --a tanka, or extended haiku
Received on Wed Aug 31 2005 - 08:15:18 PDT