Date: Mon, 13 Jul 2009 06:38:02 -0700 From: Jonathan Leffler <jonathan.leffler@gmail.com> Message-ID: <844b8e1c0907130638l21476d1bw61f78d565664ddd4@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