Brazil rule issue

[Jesper Norgaard Welen]

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

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.

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.

- Jesper Nørgaard Welen

No virus found in this outgoing message.
Checked by AVG. 
Version: 7.5.524 / Virus Database: 270.9.9/1807 - Release Date: 2008-11-23
10:59