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.

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.

--


Oracle Email Signature Logo
Patrice Scattolin | Software Development Manager | 514.905.8744
Oracle Collaborative Application Services
600 Blvd de Maisonneuve West
Suite 1900
Montreal, Quebec