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