- tz - lists.iana.org

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

FW: timezone modification for Uruguay
by Olson, Arthur David (NIH/NCI) [E] Sept. 28, 2006

Sept. 28, 2006

Toshiro is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: toshiro(a)internet.com.uy [mailto:toshiro@internet.com.uy] Sent: Thursday, September 28, 2006 12:59 PM To: tz(a)lecserver.nci.nih.gov Subject: timezone modification for Uruguay The gobernment decreed to modify the timezone every year automatically from now until further notice the first Sunday of October at 2:00 AM (1 hour forward) and the second Sunday of March at 2:00 AM (1 hour behind). url: http://www.presidencia.gub.uy/_web/decretos/2006/09/CM%20210_08%2006%202 006_00001.PDF

3 2

timezone modification for Uruguay
by toshiro＠internet.com.uy Sept. 28, 2006

Sept. 28, 2006

The gobernment decreed to modify the timezone every year automatically from now until further notice the first Sunday of October at 2:00 AM (1 hour forward) and the second Sunday of March at 2:00 AM (1 hour behind). url: http://www.presidencia.gub.uy/_web/decretos/2006/09/CM%20210_08%2006%202006…

1 0

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

Sept. 28, 2006

Then I'm confused. At the end of 1942, that rule should expire, because of the "only" leaving what rule in effect? Apparently none, leaving the time in 1943 undefined. Where can I find a explanation of the tz text database format? Thanks, ++PLS -----Original Message----- From: tz-request(a)elsie.nci.nih.gov [mailto:tz-request@elsie.nci.nih.gov] On Behalf Of Paul Eggert Sent: Wednesday, September 27, 2006 9:29 AM To: tz(a)lecserver.nci.nih.gov Subject: Re: Question on abbreviations "Mark Davis" <mark.davis(a)icu-project.org> writes: > According to the spec, TO = "only" is equivalent to saying that the TO value > equals the FROM value. Yes, that's what's happening here. The rule to switch to DST applies only in 1942. There is no rule to switch _out_ of DST in 1942, so DST continues until 1945, the next rule that applies. >> Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S >> > ... >> > Rule US 1942 only - Feb 9 2:00 1:00 W # War >> > Rule US 1945 only - Aug 14 23:00u 1:00 P #

4 6