Hi Thank you for the explanation, this will help my understanding a lot. -Alain -----Original Message----- From: Olson, Arthur David (NIH/NCI) [E] [mailto:olsona@dc37a.nci.nih.gov] Sent: Monday, November 24, 2008 5:07 PM To: tz@elsie.nci.nih.gov Cc: Alain Petit Subject: RE: Brazil rule issue The differing years on the "max" lines are correct--or, in any event, as correct as can be for now. Since there are two transitions a year--one to DST and one from DST--we do expect two "max" lines. Starting in 2008, Brazil always goes in to DST on the third Sunday of October; thus the "Oct Sun>=15" line. Improvidently, the end of DST is legislated to avoid coinciding with Carnaval; the end of DST is deferred a week if it would fall during Carnaval. So the ending ("Feb") rules need to be done on a year-by-year basis (or at least a year-range by year-range basis), accounting for the plethora of "Feb" rules. The cases are specified through 2038 (the maximum year associated with a signed, 32-bit time_t value). 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. We could get things right using the "yearistype" mechanism; there has already been some grumbling about the advisability of doing so. --ado From: Alain Petit [mailto:ALAIN.PETIT@oracle.com] Sent: Monday, November 24, 2008 4:23 To: tz@lecserver.nci.nih.gov Subject: Brazil rule issue Hi   I am looking in the Brazil rules and I was wondering if this was expected:   <snapshot>   Rule    Brazil  2007    only    -       Oct     Sun>=8   0:00   1:00    S # From Frederico A. C. Neves (2008-09-10): # Acording to this decree # <a href="http://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2008/Decreto/D6558.htm"> # http://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2008/Decreto/D6558.htm # </a> # [t]he DST period in Brazil now on will be from the 3rd Oct Sunday to the # 3rd Feb Sunday. There is an exception on the return date when this is # the Carnival Sunday then the return date will be the next Sunday... Rule    Brazil  2008    max     -       Oct     Sun>=15 0:00    1:00    S Rule    Brazil  2008    2011    -       Feb     Sun>=15 0:00    0       - Rule    Brazil  2012    only    -       Feb     Sun>=22 0:00    0       - Rule    Brazil  2013    2014    -       Feb     Sun>=15 0:00    0       - Rule    Brazil  2015    only    -       Feb     Sun>=22 0:00    0       - Rule    Brazil  2016    2022    -       Feb     Sun>=15 0:00    0       - Rule    Brazil  2023    only    -       Feb     Sun>=22 0:00    0       - Rule    Brazil  2024    2025    -       Feb     Sun>=15 0:00    0       - Rule    Brazil  2026    only    -       Feb     Sun>=22 0:00    0       - Rule    Brazil  2027    2033    -       Feb     Sun>=15 0:00    0       - Rule    Brazil  2034    only    -       Feb     Sun>=22 0:00    0       - Rule    Brazil  2035    2036    -       Feb     Sun>=15 0:00    0       - Rule    Brazil  2037    only    -       Feb     Sun>=22 0:00    0       - # From Arthur David Olson (2008-09-29): # The next is wrong in some years but is better than nothing. Rule    Brazil  2038    max     -       Feb     Sun>=15 0:00    0       - </snapshot>     There is 2 'max' entry for Brazil, one for 2008, and one for 2038. Rule    Brazil  2008    max     -       Oct     Sun>=15 0:00    1:00    S Rule    Brazil  2038    max     -       Feb     Sun>=15 0:00    0       - Reading the entries for 2012+ I feel that the one for 2008 should be a 'only' rather than 'max'.   Is that correct?   Thanks Alain Petit  

On Wed, Nov 26, 2008 at 4:19 PM, Gustavo De Nardin <gustavodn@gmail.com>wrote:

...

The cases are specified through 2038 (the maximum year associated with a signed, 32-bit time_t value). 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.

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.

I second that. Rodrigo Severo

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

2008/12/1 Patrice Scattolin <patrice.scattolin@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)

Date: Mon, 8 Dec 2008 02:55:34 -0200 From: "Gustavo De Nardin" <gustavodn@gmail.com> Message-ID: <50af0a260812072055x338351c8saadc4b8805261761@mail.gmail.com> I can't believe this discussion is still going on, or for that matter, ever started. Aside from the perfectly normal small group of messages that started this Subject header, the rest of this thread started with a quote from one of the messages that was on topic (explaining how the tz rule files work) that included ... olsona@dc37a.nci.nih.gov said: | The cases are specified through 2038 (the maximum year associated with a | signed, 32-bit time_t value). 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. to which you responded ... gustavodn@gmail.com said: | Just a note.. personally I don't think a knowingly wrong rule is "better than | nothing", Did you actually read what ado said? The "this is wrong" (that is, we expect now to have invalid data) applies to the years 2039 and beyond. What's more, the error is only sometimes, even after 2039, other years (as we understand the rules now) tzdata is going to be correct. But do you seriously believe that Brazil (of all places - perhaps the country in the world that has the hardest possible summer time decisions to make) is going to keep the rules that we believe are true now for the next 20 years, without changing them??? Personally, I'd guess that the chances of that are so insignificantly small that we can simply assume there will be a rule change for Brazil sometime between now and 2038 - when that happens (if it happens close enough to 2038 that we've started caring yet) the rules can be extended out into the future past 2039 if we still need special case handling (and assuming we're past having to deal with 32 bit signed time_t's). Now, there's the question of what to do with the rules now (the ones that will apply much sooner than 2039). Any of those might be wrong. Are you asking for them all to be deleted? That is, for the tzdata file to claim that Brazil will have no summer time from (the second half of) 2009 and beyond? That wouldn't make sense to me - there is now, as I understand it, a rule that is supposed to apply into the future, we should assume that it will continue to apply, until we get some evidence that it is changing. That is, we guess that nothing will change. We know that one day we're going to be wrong, and that anyone using the rules distributed today, is going to get incorrect time stamp conversions - some time in the future (and almost certainly, much sooner than 20 years away). It isn't just Brazil of course (and not just Brazil and Argentina), based upon historical evidence, I'd tend to guess that everywhere that has summer time, and some of the places that currently don't, are going to change their timezone rules sometime in the next 20 years. There's nothing at all we can do about this - and there's no way we can predict (too far in advance) when the various changes that are almost certain to occur, will occur (we might even get surprised and find a country that uses summer time and doesn't change its rules for the next 20 years). For now, all we can do is keep the rules as they appear to be, for the next few (or perhaps more than a few) years, for many countries, we're going to be lucky. For others we won't be and will need to make revisions and distribute new data files. Whether that's done far enough in advance that most of the affected people (in the area that changes its rules or outside it) can have updated their data just in the process of normal updates, or whether emergency updates will be needed (perhaps sometimes after the tzdata has made an error) largely depends upon the administrations that decide how much lead time from the decision to make a change, to the change actually happening is allowed. And if you think we have problems with this, just imagine what it is like for the airline industry, trying to schedule connecting flights between places where the relative clock difference changes seemingly randomly and with very little warning. If you don't want the tzdata to automatically adjust your UTC offset when it believes that summer time starts and ends in your area, just use one of the GMT-n rules instead of the area/city format, and you can run on a fixed time forever... Then if you want to change because summer time has turns on or off, you can just switch to a different GMT-m rule on the relevant day. You're going to get conversion errors in old timestamps if you do this of course, so you're just substituting one error for another (but for some people, old conversion errors don't really matter much). Alternatively you an make your own private data file with all the correct historical data, and nothing at all about the future, and see just how you really like that. Most of the world don't want that, we had that kind of thing in the past, and it was really annoying. It is much better for the system (the tzdata) to predict when summer time will start and end, and change automatically. Most of the time it is going to be correct, occasionally it won't be, either because the data hasn't been upgraded to a new enough version, or because the rules changed with too little advance warning for an update to have been distributed and installed. Sure, if you've just had to deal with problems caused by an incorrect rule, you're going to look for a way to "fix" things - but when year after year it all just works, then we're all very happy, and don't want to change a thing. If you can find a good way to tell when the difference is going to be, then please, I'm sure we all would love to know how you can do that. At the minute it sounds as if your proposal is to absndon all future data, and force people to update just before every transition (as close as possible to avoid the possibility that they may be making an incorrect change). Believe me, you don't really want that, that's what we used to have, and it was horrible. kre ps: one possibility for the future, when perhaps we can rely upon network connectivity, and have good enough and fast enough connectivity to everywhere, might be to have the database centralised (well, distributed, but to just a smallish number of sites) and have everyone else make network queries to get the rules, rather than simply finding them in a local filesystem file. That would make the update issue much less of a problem, as updates could be much more automated and timely than they are now. One day maybe, right now I don't think we really want to have to depend upon working networking before we can see the time.