- tz - lists.iana.org

FW: tzdata changes for uruguay... now it seems definitive!
by Olson, Arthur David (NIH/NCI) [E] Oct. 2, 2006

Oct. 2, 2006

Ciro Mondueri is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Ciro Mondueri [mailto:ciro@mondueri.com] Sent: Sunday, October 01, 2006 12:31 PM To: tz(a)lecserver.nci.nih.gov Subject: tzdata changes for uruguay... now it seems definitive! The Uruguayan decree now states that it will be EVERY year (at last!): +1 at 2AM the 1st sunday of october -1 at 2AM the 2nd sunday of march http://www.presidencia.gub.uy/_web/decretos/2006/09/CM%20210_08%2006%202 006_00001.PDF the patch to this file ftp://elsie.nci.nih.gov/pub/tzdata2006l.tar.gz ---------------------------------------------------------------------- --- southamerica.orig 2006-10-01 12:58:56.000000000 -0300 +++ southamerica 2006-10-01 13:07:22.543209977 -0300 @@ -1064,6 +1064,9 @@ # 02:00 local time, official time in Uruguay will be at GMT -2. Rule Uruguay 2005 only - Oct 9 2:00 1:00 S Rule Uruguay 2006 only - Mar 12 2:00 0 - +# http://www.presidencia.gub.uy/_web/decretos/2006/09/CM%20210_08%2006%202 006_00001.PDF +Rule Uruguay 2006 max - Oct Sun>=1 2:00 1:00 S +Rule Uruguay 2007 max - Mar Sun>=8 2:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Montevideo -3:44:44 - LMT 1898 Jun 28 -3:44:44 - MMT 1920 May 1 # Montevideo MT ---------------------------------------------------------------------- thanks, Ciro

1 0

FW: Timezone correction
by Olson, Arthur David (NIH/NCI) [E] Oct. 2, 2006

Oct. 2, 2006

Carlos Bergero is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Carlos Bergero [mailto:rak@fcien.edu.uy] Sent: Sunday, October 01, 2006 5:23 AM To: tz(a)lecserver.nci.nih.gov Subject: Timezone correction Due to presidential resolution Nº 1041/006 the time in Uruguay has been set to use a local summer time to save power, we still remain at time zone -3:00. Starting the first Sunday of October 2006 at 2:00 am clocks around the country should be set one hour ahead. In the 2nd Sunday of March, the following year, at 2:00 am clocks should be set back to the correct time. I had set the rules in the following manner, for now they work fine. Rule Uruguay 2006 max - Oct Sun>=1 2:00 1:00 S Rule Uruguay 2007 max - Mar Sun>=8 2:00 0 - A/P Carlos Bergero Servicio de Informática Facultad de Ciencias, U. de la R.

1 0

FW: change in Jordan daylight savings
by Olson, Arthur David (NIH/NCI) [E] Oct. 2, 2006

Oct. 2, 2006

Hilal Malawi is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Hilal Malawi [mailto:hsm6second@mac.com] Sent: Saturday, September 30, 2006 5:16 PM To: tz(a)elsie.nci.nih.gov Cc: Olson, Arthur David (NIH/NCI) [E] Subject: Re: change in Jordan daylight savings Re-reading my email, I'm embarrassed at the mistake that completely changed the meaning of the first sentence, so here is the whole message again, corrected: In its infinite wisdom the government here decided NOT to end daylight savings as usual on 29 September. Not sure exactly when they eventually will (always unpredictable), but most likely not before 20 October. So Jordan is still GMT+3. Hope this is quickly updated in TZ. Thanks. On Sep 30, 2006, at 21:01, Olson, Arthur David (NIH/NCI) [E] wrote: > Hilal is not on the time zone mailing list; direct replies > appropriately. > > --ado > > -----Original Message----- > From: hsm6second(a)mac.com [mailto:hsm6second@mac.com] > Sent: Saturday, September 30, 2006 11:48 AM > To: tz(a)lecserver.nci.nih.gov > Subject: change in Jordan daylight savings > > In its infinite wisdom the government here decided to end daylight > savings as usual on 29 September. Not sure exactly when they > eventually will (always unpredictable), but most likely not before 20 > October. So Jordan is still GMT+3. Hope this is quickly updated in TZ. > Thanks. > --Hilal

1 0

changes for southamerica file
by Ricardo Méndez Oct. 2, 2006

Oct. 2, 2006

Hello, I send you new changes for southamerica file. I Attach patch file. Sincerely, Ing. Ricardo Méndez Rodríguez Asesor Informático Prosecretaría de la Presidencia de la República Oriental del Uruguay

1 0

tzdata changes for uruguay... now it seems definitive!
by Ciro Mondueri Oct. 1, 2006

Oct. 1, 2006

The Uruguayan decree now states that it will be EVERY year (at last!): +1 at 2AM the 1st sunday of october -1 at 2AM the 2nd sunday of march http://www.presidencia.gub.uy/_web/decretos/2006/09/CM%20210_08%2006%202006… the patch to this file ftp://elsie.nci.nih.gov/pub/tzdata2006l.tar.gz ---------------------------------------------------------------------- --- southamerica.orig 2006-10-01 12:58:56.000000000 -0300 +++ southamerica 2006-10-01 13:07:22.543209977 -0300 @@ -1064,6 +1064,9 @@ # 02:00 local time, official time in Uruguay will be at GMT -2. Rule Uruguay 2005 only - Oct 9 2:00 1:00 S Rule Uruguay 2006 only - Mar 12 2:00 0 - +# http://www.presidencia.gub.uy/_web/decretos/2006/09/CM%20210_08%2006%202006… +Rule Uruguay 2006 max - Oct Sun>=1 2:00 1:00 S +Rule Uruguay 2007 max - Mar Sun>=8 2:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Montevideo -3:44:44 - LMT 1898 Jun 28 -3:44:44 - MMT 1920 May 1 # Montevideo MT ---------------------------------------------------------------------- thanks, Ciro

1 0

Timezone correction
by Carlos Bergero Oct. 1, 2006

Oct. 1, 2006

Due to presidential resolution Nº 1041/006 the time in Uruguay has been set to use a local summer time to save power, we still remain at time zone -3:00. Starting the first Sunday of October 2006 at 2:00 am clocks around the country should be set one hour ahead. In the 2nd Sunday of March, the following year, at 2:00 am clocks should be set back to the correct time. I had set the rules in the following manner, for now they work fine. Rule Uruguay 2006 max - Oct Sun>=1 2:00 1:00 S Rule Uruguay 2007 max - Mar Sun>=8 2:00 0 - A/P Carlos Bergero Servicio de Informática Facultad de Ciencias, U. de la R.

1 0

FW: change in Jordan daylight savings
by Olson, Arthur David (NIH/NCI) [E] Sept. 30, 2006

Sept. 30, 2006

Hilal is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: hsm6second(a)mac.com [mailto:hsm6second@mac.com] Sent: Saturday, September 30, 2006 11:48 AM To: tz(a)lecserver.nci.nih.gov Subject: change in Jordan daylight savings In its infinite wisdom the government here decided to end daylight savings as usual on 29 September. Not sure exactly when they eventually will (always unpredictable), but most likely not before 20 October. So Jordan is still GMT+3. Hope this is quickly updated in TZ. Thanks. --Hilal

3 2

DST change in Nicaragua one hour late
by Jesper Norgaard Welen Sept. 30, 2006

Sept. 30, 2006

The precidency of Nicaragua has emitted a decree 63-2006 about end of DST which means that according to my time and that of Steffen Thorsen, the change will occur an hour earlier at 1:00 (we had 2:00), but an hour later according to the 2006l tz database, which has the change to occur 0:00 at the moment. http://www.presidencia.gob.ni/buscador_gaceta/BD/DECRETOS/2006/D-063-2006P-P RN-Cambio-Hora.pdf My informal translation runs: The natural sun time is restored in all the national territory, in that the time is returned one hour at 01:00 am of October 1 of 2006. This probably means that the rule should be split from Rule Nic 2005 2006 - Oct Sun>=1 0:00 0 S to Rule Nic 2005 only - Oct Sun>=1 0:00 0 S Rule Nic 2006 only - Oct Sun>=1 1:00 0 S Regards, - Jesper Jesper Nørgaard Welen Email: jnorgard(a)Prodigy.Net.mx Project Leader (Líder de Proyecto) Software CIMMYT - Centro Internacional de Mejoramiento de Maíz y Trigo Dirección: CIMMYT Int. c/o Jesper Nørgaard Km. 45, Carretera México-Veracruz El Batán Texcoco, Edo. de México CP 56130 MEXICO Tel.: +52 (55) 58-04-20-04 ext. 1374 Fax: +52 (55) 58-04-75-58 Tel. Casa: 53-10-05-95 ó 53-10-97-78 Download the shareware program World Time Explorer, I made: http://www.worldtimeexplorer.com/index.html

1 0

change in Jordan daylight savings
by hsm6second＠mac.com Sept. 30, 2006

Sept. 30, 2006

In its infinite wisdom the government here decided to end daylight savings as usual on 29 September. Not sure exactly when they eventually will (always unpredictable), but most likely not before 20 October. So Jordan is still GMT+3. Hope this is quickly updated in TZ. Thanks. --Hilal

1 0

RE: Question on abbreviations
by Paul Schauble Sept. 29, 2006

Sept. 29, 2006

So in this case: Rule US 1942 only - Feb 9 2:00 1:00 W # War Rule US 1945 only - Aug 14 23:00u 1:00 P # Peace Why is %s undefined in 1943? This was the question that started the thread. If the time setting carries forward, surely the letter should also. ++PLS -----Original Message----- From: tz-request(a)elsie.nci.nih.gov [mailto:tz-request@elsie.nci.nih.gov] On Behalf Of Ken Pizzini Sent: Wednesday, September 27, 2006 3:14 PM To: tz(a)lecserver.nci.nih.gov Subject: Re: Question on abbreviations On Wed, Sep 27, 2006 at 02:37:58PM -0700, Mark Davis wrote: > I share your confusion. If Paul (Eggert's) description is right, then I have > to ignore the TO field in some circumstances which are entirely unclear to > me. I would much rather see the TO field corrected. That is, if TO=1942 is > ignored, and 1945 is the real date, then the line should be corrected to > TO=1945. The key to understanding is that the rules describe a list of *transitions*. After a transition, the described effect on zone offset and abbreviation *remain* in effect until the next transition. The "TO" part of a rule is used to enable a shorthand for a _recurring_ transition, such as "first Tuesday of February", for all years within the range. If "to" is "only", then the *transition* being documented is a singleton, but the transitioned-into offset/abbreviation remains in effect until the _next_ transition, no matter how far in the future. > There are other failures in the parsing. My error messages are: ... > I looked into why this is happening, and found: > > Zone Europe/Amsterdam 0:19:32 - LMT 1835 > 0:19:32 Neth %s 1937 Jul 1 > But the first LETTER/S defined by Neth is in 1916, so during the range from > 1835 to 1916 this is undefined. If the LETTER/S are magically also defined > *before* the first FROM, that should be described in the specification. Yes, this is a failure of the documentation. If a Zone refers to a time within a Rule that is before the first transition mentioned for that rule, then the _oldest_standard_time_ "Letter/s" is used. In this case, AMT. > BTW, the documentation was a first a bit confusing to me, since it says that > fields are delimited by spaces, and lists a single Zone UNTIL field. > However, if you look carefully at the documentation, there are really 4 > fields: > > UNTIL_YEAR UNTIL_IN UNTIL_ON UNTIL_AT > > which are optional [but only in "truncation" from the end: that is, it > corresponds to the (Perl) regex (UNTIL_YEAR (UNTIL_IN (UNTIL_ON > (UNTIL_AT)?)?)?)?]. > > I'm not the only one to have initially made this mistake: the proposed XML > format for the TZ database makes the same mistake. Confusing: granted. Whether "Until" is one or multiple fields is a matter of interpretation. The _traditional_ understanding is that it is a *single* "timestamp field" which may happen to have spaces within it. BTW the subfields aren't "YEAR IN ON AT", but "YEAR MONTH DAY TIME". In this regard, a recent addition to the tzcode tarball is zoneinfo2tdf.pl, which translates the more free-with-spaces zone tzdata into a form which strictly uses a single tab between fields. This may make life easier for some by simplifying their parser's requirements. (Or not.) --Ken Pizzini

5 12