Steve Allen wrote:
Someone please tell me again why the zoneinfo files would need 10
years of advance notice if they were to absorb responsibility for
leap seconds.
Rather the opposite. Nobody would object if the schedule for
announcing leapseconds could be extended to 10 years (all else being
equal). On the other hand, world governments would balk at any
attempt to limit their sovereignty by requiring a 10 year lag before
timezone and DST changes could take effect. The scientific community
is clearly more accommodating here than the political community.
A parable: NOAO has facilities in southern Arizona and northern
Chile. Neither Chile nor Arizona underwent a daylight saving time
change on March 9, and yet both encountered DST goofs on that day.
Arizona doesn't observe DST (the last thing we need to save is
daylight), and the government of Chile decided to extend DST for the
southern summer for a few extra weeks this year.
Several "atomic" wall clocks reset themselves in Arizona. They
actually fell back, rather than forward (?!?) - best guess is that
they had been set to Pacific time + DST and the DST flag was
interpreted as a toggle (thus shifting to standard time). Sounds
pretty lame, but that's what the clocks did.
A large number of NTP synced unix clocks (various flavors) in Chile
automatically moved back to standard time since the configurations
weren't updated in a timely fashion.
One would expect the stress of rising energy prices combined with the
rather contradictory logic of DST regarding saving energy to only
result in additional short notice government timekeeping decisions.
This suggests that there is a requirement for an improved
infrastructure for managing timezone information, and not to allow the
infrastructure to wither. The only alternative is chaos.
Poul-Henning Kamp wrote:
Because stupid handling of timezones is something politicians you
vote for do, and consequently there is a feedback loop that can
discourage such behaviour.
Leapseconds are mandated by a bunch of scientists who are not
accountable for anybody if they suddenly decide to issue leapseconds
with 1 month notice.
It is a neat trick to accuse one party (scientists) with the crime of
the other (politicians).
Scientists are much more accountable through funding agencies, etc.,
than any government entity. Note also, of course, that not all
stakeholders have the opportunity to vote for their politicians. And
what is the ITU but a mechanism for holding a "bunch of scientists"
accountable? With absolutely zero irony, this mailing list can be
described as such a feedback mechanism.
The ultimate feedback loops for timekeeping are the natural rhythms
that govern our civil institutions and technical infrastructure. We
(scientists or politicians) are not free to willy-nilly redefine the
clock and the calendar. In particular, the clock is a subdivision of
the calendar. The ITU initiative refers to leap seconds, but it is
really an attempt to change the definition of the "day".
I've gotta say that I'm perplexed at your reception of Steve's
suggestion. Your own idea (correct me if I'm wrong) is that the
secular clock drift due to embargoed leap seconds will be accommodated
via local adjustments to the standard timezone system. Steve has
simply fleshed out the details for one such mechanism to manage all
the local adjustments coherently.
If leap seconds aren't going to carry the weight of civil time
anymore, than this weight will fall somewhere else. If it falls onto
the system of timezones, then the timezones will have to be reinforced
to bear the weight. If not via zoneinfo, then how?
John Hein wrote:
For those applications that do care about local time, there are
other forums for discussing this class of problem. It's certainly a
real issue for some, but is separable from the issues associated
with leap seconds.
It is precisely that UTC is kept stationary with respect to mean solar
time that permits local timezone issues like DST to be separable from
UTC as you describe.
Rob Seaman
National Optical Astronomy Observatory
_______________________________________________
LEAPSECS mailing list
[email protected]
http://six.pairlist.net/mailman/listinfo/leapsecs
