Brazil rule issue

[Gustavo De Nardin]

2008/12/1 Patrice Scattolin <patrice.scattolin at oracle.com>:
>
> I would advocate in favor or rules that are correct most of the time but can
> sometimes be wrong.
>
> It's not just the matter of the clock of the machine being off being a
> problem but it's also a problem for applications that rely on the TZ
> database to schedule meeting in the future. Knowing when a timezone change
> will occur weeks and even months in advance is important to make sure that
> the meetings in the future are properly scheduled. An absence of rule would
> put far more meetings at the wrong time, something that can't be an
> improvement.

Meetings are hardly scheduled without human intervention and
dates/times confirmation with actual persons. Also, having a
consistent problem is better than having an unexpected one. (i.e. if
the meeting is missed due to bad schedule, the new schedule may
account for the error, but if the rule was "wrong" this week, but next
week it will be "right", the meeting may be missed again)


> Jesper Norgaard Welen wrote:
>
> 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.
>
>
>
> What is the alternative? Ignore the presence of DST completely until the
> government makes the expected determination 2 days before the switch? That's
> even worst because a far longer period of time will be affected with wrong
> information.
>
>  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.
>
>
> Absolutely correct. While users might tolerate a few weeks of inconvenience,
> half a year is much longer to swallow.

IMHO the worst inconvenience is the rule kicking in at the wrong time
*after* people have worked it around.


-- 
(nil)