Brazil rule issue
Gustavo De Nardin
gustavodn at gmail.com
Mon Dec 8 04:55:34 UTC 2008
2008/11/30 Jesper Norgaard Welen <jnorgard at 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
> 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
> 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
> 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
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
> 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.
More information about the tz