proposed time zone package changes

[Robert Elz]

    Date:        Mon, 13 Jul 2009 06:38:02 -0700
    From:        Jonathan Leffler <jonathan.leffler at gmail.com>
    Message-ID:  <844b8e1c0907130638l21476d1bw61f78d565664ddd4 at mail.gmail.com>

  | The database would surely just need to encode things so that at some point
  | in time after the move to 'permanent summer time', the TZ string would
  | simply be:
  | 
  |     TZ=XYZ-9

yes, between when I sent my reply, and then receiving Dave's and then your
replies I understood better what you're meaning.

Currently, to handle times into perpetuity, zic installs a POSIX type
string to represent times beyond those explicitly encoded into the
binary file, ans so allows localtime() to attempt to make a better
guess at (far) future timestamps than if it were to simply assume
continuous standard time (or something).

It (currently) does that by assuming that the final year about which
data is known (well, guessed) should apply in all future years.
That's what is failing here, Dhaka's current rule simply cannot apply
every year.

For this case, I don't actually think it matters one way or the other,
we can be 99.99% confident that we're going to be generating incorrect
timestamps for Dhaka (and the rest of Bangladesh) for times later in
2009 - that we keep doing that further into the future hardly seems like
a big problem.

But in general, Dave's suggested solution does seem like it might be
better - to handle a genuine case of a zone which decided to switch
to 100% summer time during some year (after which there would be no
more explicit rules of course).

That also perhaps suggests a better solution for Dhaka now, than the
one ado proposed - a zone that switches to summer time, and never
switches back, is just a zone that changes its base timezone.
That weve seen and handled before, in fact as essemtially all zones
start with their LMT zone data, for the period before the introduction
of standard time, maybe a better (short term) fix for Dhaka, would be
to simply encode its 1009 summer time switch on as a timezone change for
now (along with a zone name abbreviation change) - the effect visible
externally should be the same, but we'd be back in familiar territory,
and not need the fictitious end data, and the code) (even old code)
should be able to handle it OK.

When we know when summer time in Bangladesh is set to end, the
representation can be changed back to being a normal summer time on/off
set of transitions.

  | This problem faces all the data.  There is no assigned date for when the USA
  | will next change its rules, but I'm sure it will happen, and probably before
  | I retire.

Sure, but there is a difference in degree...   for the US (and Europe,
Australia, and most other places) there's a fair degree of confidence
that the rules we have are plausible, and until there's specific ation
taken to change them, using that data into the future is as good as
is possible to do.

For the Dhaka ruleset, we know (well, assume with a high degree of confidence)
that sometime, probably September or October sometime, they will switch
back to standard time - they just seem to have not yet selected when
that should happen (or if they have, they're not telling us).  (How the
airlines cope with this I hate to imagine).

Recall the problems we had in Argentine when we didn't have the exact
correct date for their transition, and the annoyance that caused people,
because we had at least a reaosnable assumption encoded in the rules.
Encoding random (unreasonable) guesses would be even worse.

  | I'm not convinced there is no valid TZ string...the outline value I showed
  | would be correct (the same as it is for UTC0).

Yes, the "no valid" assumes the current practice of assuming that the
last year for which we have rules should continue forward indefinitely.

  | The arbitrary end date is probably a necessary fiction, like the fiction
  | that the rules in the USA won't change in the future.

Not quite the same, and if we were to switch the way the change on June 19
is represented in the rules, and make it be a time zone alteration, rather
than a summer time start, then I think we don't need the fiction to
allow zic to work correctly.

kre