Re: [LEAPSECS] Mechanism to provide tai-utc.dat locally

From: Zefram <>
Date: Wed, 27 Dec 2006 02:23:24 +0000

Tony Finch wrote:
>You should treat this kind of conversion in the same way that you treat
>local time zone conversions, which are also unpredictable.

I wish timezone data would come with a guaranteed validity period,
so that the library could say "I don't know" in the right places.
Unfortunately timezones are much less predictable than leap
seconds. Not only do legislatures change the rules from year to
year, sometimes they change their minds with only weeks of notice.
See <> for a rather
sudden extension of DST in Brazil in 2002. I think to avoid ever giving
inaccurate timezone data we'd have to refuse conversions that are any
more than a day in the future.

Even if some governments were to set timezone rules well in advance
with guaranteed validity periods, others wouldn't bother and so the
timezone situation would remain generally a mess. It's fundamentally
much less controlled than the precision timescales that are defined by
international organisations with subject-specific expertise.

In addition, the changes that are made to timezones are of much larger
magnitude than we must deal with in UTC. Under current practices,
future timezones can be approximated by longitude, with an uncertainty
of about three hours in each direction. For locations in the Pacific
there's the additional uncertainty of which side of the international
date line they'll be on.

So I'm not convinced that leap second uncertainty and timezone uncertainty
should be treated the same way. The nature of the uncertainty is
very different. The uncertainty of future UTC can be managed, but for
timezones the only sane path is to eschew their use entirely.

Received on Tue Dec 26 2006 - 18:23:54 PST

This archive was generated by hypermail 2.3.0 : Sat Sep 04 2010 - 09:44:55 PDT