Ezequiel Colombo escribió el 08/10/08 14:18:
I strongly agree with Nicolas, the event last week was caused by a previous *guess* as you can see here (http://article.gmane.org/gmane.comp.time.tz/2015) and has been causing several problems in our systems these days. Our government hasn't released any new law describing DST for this year so there isn's any reason to include 2008 (and future) Rules for Argentina.
In my case i haven't included the '08s Rule in my tzdata last year, but i'm using some JAVA software that has included it in their tzupdater tool. Now i have to wait for a fixed tzdata and then wait for SUN to release the tzupdater tool including that tzdata.
Please do not make the same mistake twice, the rules should be based on laws or formal government announcements.
Hi folks... sorry 'bout me being silent so long... I have some personal problems (added to the fact that I also work for a living, which I guess Olsen, Eggert, Elz and most people on this list also do)... Let's put a couple of things in perspective... For starters, I had the same problem as most sysadmins in Argentina since I use the standard debian/ubuntu upgrades and tzdata2008f had not been installed in my machines by last Sunday (see my post -in Spanish- at http://clueless.com.ar/articles/que-hora-es). As Ezequiel notes, tzdata updates take some time to find its way into different unix distros, let alone java (and maybe other) runtime / development environments... and in most unixes, at least an average sysadmin always has a way to dowload the current tzcode/tzdata and have it up to date, I don't think an average developer is able to download the current tzdata and generate a working jre that inlcudes it. Nicolás is in part right than given our government's lazyness (stupidty?) in not defining this with a reasonable prevision (6 months seems reasonable to me), in that from the sysamdin pov it'd be better to not put *any* dst rule until there's an official decree (note that there actually *is* a Law, from December, and it's so stupid that instead of puting a clear rule for changing dst and allowing it to be modified by the Executive Branch, it forces the Executive to pass a decree *every year*). Most sysadmins in Argentina (me included) were not thinking about dst last week because nothing was spoken about it in the media or anywhere else and we definitively don't have a tradition of /regular/ dst changes, (I can't seem to understand why). All of us raised tickets in our distros' bug trackers... in some cases pointing at simply the need for an upstream sync, in other cases without any clue as for where the problem is (that's ok, most of the time I raise a case, I don't have a clue of where the problem is, or if it is distro-specific or upstream or whatever)... some distro maintainers got accused of having false data (even after the update to 2008f/g, because of the tentative Oct-19 change) and some of them pointed their fingers here... Anyway, shouting at distro and tzdata maintainers and pointing fingers won't do any good... What we can do is to discuss what is the best strategy for updating tzdata in the lack of oficial data... in order to do this, we must put in perspective what tzdata is and what its maintainers do... 1) I am nobody here... I don't maintain anything and nobody called me or elected me to do anything... I am just a simple tzdata user who lives in Argentina and in the past I've been indirectly responsible for the administration of a few important servers where I thought it was important to have the date and timezone correct. 2) If I understand it correctly, Arthur David Olson is the official maintainer of tzcode and tzdata... I suspect (but I don't know or care) that he was kind of self-appointed or was appointed by his employer (which, for his mail address, I guess is the National Cancer Institute in the USA). I understand he is the main coder here... 3) For what I've seen, Paul Eggert is somehow the "database master" of tzdata (maybe the one who is more fluent with it?) and does most of the editing (I guess it is also somehow self-appointed). 4) I've seen Robert Elz here for years... I don't know if he has an offiical role in tzcode/tzdata, but he always participates in the mailing list, with opinion about code bugs, database information and policy. 5) Through the last 7 years that I've been subscribed to the list ('thought the list is much older than that), these three people and many, many more have worked for me for free on demand... Whenever I found I needed to change data in the database (because there would be a change in Argentina which wasn't there), I simply had to find some reasonable source for it and explain in plain English what the change would be, Paul would translate my words into tzdatese giving me a patch that I could apply immediatly and David would publish it a few days later... and all for a nice and simple "thank you guys" here and there... I know, they had side-benefits, because now they have 2 grains of my little knowledge sand in their information dune, but they didn't especially needed it since, sooner or later one of them would've found out somewhere that Argentina would change its timezone rules that year. 6) I know David and Paul would like to have more up to date information about Argentina, but my daily problems make me quite ungrateful to them so I come here only when I want and don't participate on a regular basis (and in spite of that, they keep working for me)... every know and then another Argentinian stops by... sometimes with information, sometimes only to complain about wrong data (this happens with people from everywhere, I'm just being local about a country which hasn't many people participating in this list)... I know David and Paul would also like /them/ to participate more, but they don't complain, so let's not complain about wrong data, but only point it out (so they can fix it for us... again, free of charge). And now for what we can do: We could keep our policy of "informated guess" (the most informators, the better the guess) and risk having the problems that happened last Sunday... the other policy would be "wait and see" which might have worked better this time, but I am not sure. As for the problem that Ezequiel poses (about java's tzdata implementation)... I don't program in java (nor any other language, for that matter) but, as I stated above, I don't know if Joe Average Java is able to generate by himself a jre or jdk or whatever that be given an updated tzdata file or if he has to wait for Sun to publish a patch or release or something... In the later case, my guess is that the "guess and publish soon" policy in the long rung will work better... question... when the Law 26.350 was published on December 28th, 2007 ruling a dst change at 0:00 December 30th (that is less than 48 hours in advance)... how long it took to have the java timezones right? I think we should keep the current policy (though we *should* keep discussing it and the discussion may make me change my opinion). Anyway... I just heard on the radio that *apparently* dst *would* change in Argentina next Sunday (so 2008f/g *would* be valid)... I didn't find official info about it, but I'll try to look for it later today. Regards. -- Mariano Absatz - "El Baby" baby@baby.com.ar -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- I am a Marxist--of the Groucho tendency. Anonymous, French slogan -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- * TagZilla 0.066 * http://tagzilla.mozdev.org