proposed time zone package changes (Argentina, Mauritius, Niue, Syria)

Thu Oct 9 13:15:27 UTC 2008

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 at baby.com.ar

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
I am a Marxist--of the Groucho tendency.
        Anonymous, French slogan
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
* TagZilla 0.066 * http://tagzilla.mozdev.org