2008/11/30 Jesper Norgaard Welen <jnorgard@prodigy.net.mx>:
David Olson wrote:
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.
Gustavo de Nardin wrote:
Just a note.. personally I don't think a knowingly wrong rule is "better than nothing", it forces the sysadmin to fix the clock 2 times. I think when there's no good rule "forever", make it apply only for the known cases and leave it alone so the admin can easily handle it on his own if needed. Not gonna happen anytime soon in this case, but happened almost every year in Brazil before this new rule.
Let me explain why I think this view is wrong. It has been issued extensively by the Argentinian and Brazilian sysadmins that were trying to mend the lack of clear answers about time zones from their respective governments, with quick patches either when the clocks had actually changed (sigh!) or when there was something that looked as authoritative information about a future implementation. I agree that when only handling current time for a computer running on a given time zone, and no certain information is known, it is easier to let the time run indefinitely without DST, and then only apply when the current time literally changed to DST. Or at least 50% of the cases, when the actual application of DST happens *after* our best guess.
However, there are many different uses of the tz database, and running a computer on a tz database time zone as real time, is not the most significant use of the database
You may be right about this, but still most of the affected people are the ones living in the affected time zones.
in my opinion. After all if there are 265 countries then there are 263 countries that couldn't care less if Argentina or Brazil time zone is wrong. For them it would be nicer to have an approximate guess of all time zones that is not their own.
For each country for which we assume that DST will happen but can't be sure, the sysadmins of that country should prepare a patch well in advance for that country of not applying DST all year, and then let other uses of the tz database continue with their best guess approach for the country. When it becomes clear when DST will be applied, a second patch can be prepared to enforce that new rule. Don't just sit there passively until finally the tz database rule actually kicks you by changing your computer time, and *then* scramble a patch. That makes you just as guilty as the Politicians for lack of action.
Obviously, but still a lot of people are caught up. It may just not be really obvious to people that selecting a "time zone" also determines daylight savings time periods.
Many different software projects and implementations exist, for which rapidly creating and applying a patch is not realistic. To mention a few Joda-time, Ipods, the average Linux computer without a sysadmin etc. I think there is still a software implementation that uses tz data from 2006! If we had scheduled Brazil wihtout DST in 2006 after that year, the software would still run with years 2007 and 2008 as not having DST. From that perspective, an approach of DST that were a few weeks off, to having half the year wrong, is clearly a worse result.
I see, but I think looking from that POV, keeping the wrong rule in the TZ database is actually *worse*: if you have a device you can't patch (e.g. a wireless router) carrying an old and wrong DST rule, then you have *no way* to fix that device beforehand, and you also have a hard time predicting which version of the database, thus which old rule (thus which day the rule starts/ends) will be in effect.
My conclusion is that sysadmins of countries that don't come forward in good time with rules, should carry the burden of this patching, not the rest of the tz community. Let's not blame the Messenger for the fact that the war was lost.
I don't think it'd affect more that a very little fraction of the TZ community. -- (nil)