FW: About rules for Brazil

John Cowan cowan at mercury.ccil.org
Mon Oct 21 19:44:28 UTC 2002

Paul Eggert scripsit:

> In this month's case you would be right, of course; but I suspect that
> it will be just as common for the clocks to be advanced ahead of our
> guess as behind, and there your proposed strategy would fail just as
> badly as the tz database's current approach.

However, I think the important point is that the database not impose
guesses about the utterly uncertain future.  It is fair enough to
guess that U.S. DST will stay the same, since it has been quite stable.
But guessing that next year in Brazil will be like last year, when last
year was not like the year before, and so on, strikes me as bogus.

In short, I agree that "only" should be the rule here.

> A similar situation obtains in Israel, where the guesses after 2004
> are quite arbitrary.  However, for the few applications that need
> access to future civil time (planning airplane trips?) I think it
> better to have a good guess than to guess that there will be no DST at
> all.

I see your point, but in fact airplane trips are *not* the only case.
Any time you make an appointment to do something or meet someone in
the future, you are implicitly making it in civil time for the place
of the appointment.  If I say to someone "Meet me under the Waverley
[that's a place in Manhattan] at midnight, New Year's Eve 2004" , then
the appointment is set for midnight *local time* whatever that may be.
For a more commercial example, when a stock tender or a futures option
expires as of 5 PM, New York time, on such-and-such a day, that means
at whatever GMT time Congress decrees is equal to 5 PM New York time *as
of that day*.

I have been for some years now telling people who are not on this mailing
list that it is safe to use GMT or GMT+offset for present and past times,
but that when an application stores future times, it should store a local
time and a timezone name.  Even this is not infallible -- we don't know
how the TZ system will work in the year 2076 -- but it's a lot better
than storing a GMT+offset and hoping nothing weird happens.

John Cowan                                <jcowan at reutershealth.com>     
http://www.reutershealth.com              http://www.ccil.org/~cowan
Yakka foob mog.  Grug pubbawup zink wattoom gazork.  Chumble spuzz.
    -- Calvin, giving Newton's First Law "in his own words"

More information about the tz mailing list