Brazil rule issue

[Robert Elz]

    Date:        Mon, 8 Dec 2008 02:55:34 -0200
    From:        "Gustavo De Nardin" <gustavodn at gmail.com>
    Message-ID:  <50af0a260812072055x338351c8saadc4b8805261761 at mail.gmail.com>

I can't believe this discussion is still going on, or for that
matter, ever started.

Aside from the perfectly normal small group of messages that started
this Subject header, the rest of this thread started with a quote
from one of the messages that was on topic (explaining how the tz
rule files work) that included ...

olsona at dc37a.nci.nih.gov said:
 | The cases are specified through 2038 (the maximum year associated with a
 | signed, 32-bit time_t value). After that (through year "max") the rules say
 | that DST ends the third Sunday of February every year; this is wrong by a
 | week in some cases but is better than nothing. 

to which you responded ...

gustavodn at gmail.com said:
 | Just a note.. personally I don't think a knowingly wrong rule is "better than
 | nothing",

Did you actually read what ado said?  The "this is wrong" (that is,
we expect now to have invalid data) applies to the years 2039 and beyond.
What's more, the error is only sometimes, even after 2039, other years
(as we understand the rules now) tzdata is going to be correct.

But do you seriously believe that Brazil (of all places - perhaps the
country in the world that has the hardest possible summer time decisions
to make) is going to keep the rules that we believe are true now for the
next 20 years, without changing them???

Personally, I'd guess that the chances of that are so insignificantly
small that we can simply assume there will be a rule change for Brazil
sometime between now and 2038 - when that happens (if it happens close
enough to 2038 that we've started caring yet) the rules can be extended
out into the future past 2039 if we still need special case handling
(and assuming we're past having to deal with 32 bit signed time_t's).

Now, there's the question of what to do with the rules now (the ones
that will apply much sooner than 2039).   Any of those might be wrong.

Are you asking for them all to be deleted?  That is, for the tzdata file
to claim that Brazil will have no summer time from (the second half of)
2009 and beyond?

That wouldn't make sense to me - there is now, as I understand it, a
rule that is supposed to apply into the future, we should assume that it
will continue to apply, until we get some evidence that it is changing.
That is, we guess that nothing will change.   We know that one day
we're going to be wrong, and that anyone using the rules distributed
today, is going to get incorrect time stamp conversions - some time in
the future (and almost certainly, much sooner than 20 years away).

It isn't just Brazil of course (and not just Brazil and Argentina),
based upon historical evidence, I'd tend to guess that everywhere that
has summer time, and some of the places that currently don't, are
going to change their timezone rules sometime in the next 20 years.

There's nothing at all we can do about this - and there's no way we
can predict (too far in advance) when the various changes that are
almost certain to occur, will occur (we might even get surprised
and find a country that uses summer time and doesn't change its rules
for the next 20 years).

For now, all we can do is keep the rules as they appear to be, for
the next few (or perhaps more than a few) years, for many countries,
we're going to be lucky.   For others we won't be and will need to
make revisions and distribute new data files.  Whether that's done
far enough in advance that most of the affected people (in the area
that changes its rules or outside it) can have updated their data
just in the process of normal updates, or whether emergency updates
will be needed (perhaps sometimes after the tzdata has made an error)
largely depends upon the administrations that decide how much lead
time from the decision to make a change, to the change actually
happening is allowed.

And if you think we have problems with this, just imagine what it
is like for the airline industry, trying to schedule connecting flights
between places where the relative clock difference changes seemingly
randomly and with very little warning.

If you don't want the tzdata to automatically adjust your UTC offset
when it believes that summer time starts and ends in your area, just use
one of the GMT-n rules instead of the area/city format, and you can
run on a fixed time forever...  Then if you want to change because
summer time has turns on or off, you can just switch to a different GMT-m
rule on the relevant day.

You're going to get conversion errors in old timestamps if you do this of
course, so you're just substituting one error for another (but for some
people, old conversion errors don't really matter much).   Alternatively
you an make your own private data file with all the correct historical
data, and nothing at all about the future, and see just how you really
like that.

Most of the world don't want that, we had that kind of thing in the past,
and it was really annoying.  It is much better for the system (the tzdata)
to predict when summer time will start and end, and change automatically.
Most of the time it is going to be correct, occasionally it won't be,
either because the data hasn't been upgraded to a new enough version, or
because the rules changed with too little advance warning for an update to
have been distributed and installed.

Sure, if you've just had to deal with problems caused by an incorrect
rule, you're going to look for a way to "fix" things - but when year after
year it all just works, then we're all very happy, and don't want to change
a thing.   If you can find a good way to tell when the difference is going
to be, then please, I'm sure we all would love to know how you can do that.

At the minute it sounds as if your proposal is to absndon all future
data, and force people to update just before every transition (as
close as possible to avoid the possibility that they may be making
an incorrect change).   Believe me, you don't really want that, that's
what we used to have, and it was horrible.

kre

ps: one possibility for the future, when perhaps we can rely upon network
connectivity, and have good enough and fast enough connectivity to
everywhere, might be to have the database centralised (well, distributed,
but to just a smallish number of sites) and have everyone else make network
queries to get the rules, rather than simply finding them in a local
filesystem file.   That would make the update issue much less of a
problem, as updates could be much more automated and timely than they
are now.   One day maybe, right now I don't think we really want to have
to depend upon working networking before we can see the time.