On 02/08/2011 16:30, Rob Seaman wrote:
Even the olson database won't give you all the answers, but it will give you
many of them.
But you guys continue to reject Steve Allen's zoneinfo option...which
represents a system layered on a relatively static timezone DB. Punting to
local governments is vastly more complex.
The basic problem with that approach is that you need to update your
timezone files for every leap second, and you can never, ever, miss an
update, or you are hozed. NTP also does everything in UTC time, so if
you come up with one set of data, then get updated timezone info that
tells you that you missed a leap second, the underlying clock running in
TAI time will suddenly be a second off. This can be mitigated somewhat
if you have a working GPS receiver and can afford to wait the 30 minute
it may take to get the almanac data to startup, but there are still a
large number of situations where you don't know until 'later' that
you've made the wrong guess at startup and now everything you've based
on a TAI or TAI-like time in your application is off by 1 or more seconds.
At least some versions of the timezone code also don't re-read the
zonefiles if they change (stating these files every time operation is
prohibitively expensive). This means long-running control programs will
have systematic errors depending on when they were started relative to
the timezone files. And having the program itself restart also has issues.
If time were always broadcast in TAI, and if the number of leapseconds
was always available, then these issues would go away. But it isn't.
As the number of these issues you try to code around grows, the
complexity reaches a point where you say "geeze, this was a stupid idea."
Warner
_______________________________________________
LEAPSECS mailing list
[email protected]
http://six.pairlist.net/mailman/listinfo/leapsecs
