Brazil rule issue

Rodrigo Severo rodrigo at
Sun Nov 30 10:32:44 UTC 2008

On Sun, Nov 30, 2008 at 1:25 AM, Jesper Norgaard Welen
<jnorgard at> wrote:
> 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.

But if these sysadmins "couldn't care less if Argentina or Brazil time
zone is wrong" why bother with their needs on this matter? As you
stated yourself, they "couldn't care less" ;)

The sysadmins represented here by the ones defending the position of
not trying to guess future DSTs do care a lot. Care enough to argue
their position here.

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

I see your point of view but again you are defending that the ones
that do care about this issue have extra work so that the ones that
don't care about this issue don't get a result you say would be bad
for them. But they don't care even to support this position. Let the
guys that don't care not care in peace. Let the ones that care have
the best setup to deal with the situation.

And lets understand exactly how your proposition of not "sit there
passively" would work:
* First every concerned sysadmin have to identify which transitions
are guessed by TZ and which ones are really derived from a proper
government determination. I really don't think this is an easy task
for those that are following this list, imagine for the ones that
don't follow this list but still care about their machines having
their clocks at the proper timezone/DST configuration. Please don't
argue that all the ones that care about their clocks should follow
this list as this would be unrealistic and impratical. But lets assume
this step is accomplished somehow;
* They I set some reminder to warn me twice a year that a DST
transition is scheduled in TZ for a timezone that I do care about so I
can check if it's right or wrong. Now there are three possibilities we
have to consider:
1. the date for the transition at stake has been already defined by
the government and it's right - wonderful, nothing extra to be done
and everybody is happy;
2. the date for the transition at stake has been already defined by
the government and it's wrong - everybody that cares about this
transition has to fix their setups, including the TZ maintainers;
3. the date for the transition at stake has not been defined by the
government yet so I have to unset the current transition so later,
when it's set I go back to option 2 above. Extra work necessary by the
ones that care about this issue.

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

As you mentioned Brazil lets state the facts correctly: we are not
talking about a few weeks X half a year but few weeks X 4 months.

And again, do these people care about Brazil's timezone/DST? If they
do, go for the proper configuration. If they don't care, let them not
care in peace.

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

If the issue at stack was choosing who gets the burden I would agree
with you but I don't think it is. The issue as I see is: do the ones
that care about should have more or less work? The TZ community will
have the work of fixing the rules anyway as TZ community wants to get
the rules as correct as it gets. And apparently you are arguing that
the ones that care should have more work so the ones that don't care
would have a result you say is better for them but we are not even
sure about it as they, the ones that don't care, don't care even to
agree or disagree with you because they, as you said, don't care.

I'm not sure there is a mission statement for the TZ package (and I
confess I haven't even looked around for one) but would this mission
statement (real or imaginary) look more like:

"The TZ package strives to have the most faithfull representation of
the world timezones since 1970 as far as the best info the TZ
community gets."

or more like

"The TZ package strives to have the most faithfull representation of
the world timezones since 1970 as far as the best info the TZ
community gets plus a few guesses so people that don't care about
these guessed timezones don't have them too wrong."?

Ok, this last argument isn't really solid but it's kind of funny so I
couldn't let the opportunity pass.

Best regards,

Rodrigo Severo

More information about the tz mailing list