On Wed, 27 Dec 2006, Zefram wrote:
>
> So I'm not convinced that leap second uncertainty and timezone
> uncertainty should be treated the same way.
I was thinking partly from the point of view of infrastructure: if you
have a mechanism that can keep the system's timezone database up-to-date,
then it is adequate for keeping the leap second table up-to-date. This is
an approach to answering Ashley's initial question, and the one taken by
Linux's use of the Olson database (though its implementation is far from
ideal).
> 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.
That isn't possible for applications like appointment books and job
schedulers. As Warner suggests, you need to calculate future times
provisionally, and in a way that insulates you from discontinuities.
For example, "same time tomorrow" instead of "in 86400 seconds".
Tony.
--
f.a.n.finch <dot_at_dotat.at> http://dotat.at/
FAIR ISLE FAEROES SOUTHEAST ICELAND: SOUTH OR SOUTHWEST 4 OR 5, DECREASING 3
IN FAIR ISLE. MODERATE. FAIR. MODERATE OR GOOD.
Received on Tue Dec 26 2006 - 20:17:10 PST