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
> 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)



More information about the tz mailing list