Brazil rule issue
Jesper Norgaard Welen
jnorgard at prodigy.net.mx
Sun Nov 30 03:26:23 UTC 2008
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
the Argentinian and Brazilian sysadmins that were trying to mend the lack of
answers about time zones from their respective governments, with quick
when the clocks had actually changed (sigh!) or when there was something
as authoritative information about a future implementation. I agree that
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
then only apply when the current time literally changed to DST. Or at least
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
a tz database time zone as real time, is not the most significant use of the
in my opinion. After all if there are 265 countries then there are 263
couldn't care less if Argentina or Brazil time zone is wrong. For them it
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,
of that country should prepare a patch well in advance for that country of
DST all year, and then let other uses of the tz database continue with their
approach for the country. When it becomes clear when DST will be applied, a
can be prepared to enforce that new rule. Don't just sit there passively
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
Many different software projects and implementations exist, for which
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
software would still run with years 2007 and 2008 as not having DST. From
an approach of DST that were a few weeks off, to having half the year wrong,
is clearly a
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
More information about the tz