Date: Mon, 8 Dec 2008 02:55:34 -0200 From: "Gustavo De Nardin" <gustavodn@gmail.com> Message-ID: <50af0a260812072055x338351c8saadc4b8805261761@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@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@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.