September 2006 - tz - lists.iana.org

proposed tz change for Latvia, Lithuania
by Paul Eggert May 25, 2015

May 25, 2015

It's March Madness time for daylight-saving rule changes. Here's a proposed change to the tz database to keep up with the latest political development, which affects time stamps starting March 29: * Latvia and Lithuania will not observe DST, starting this year. Thanks to Andrei Ivanov for this info. =================================================================== RCS file: RCS/europe,v retrieving revision 2000.3 retrieving revision 2000.3.0.1 diff -pu -r2000.3 -r2000.3.0.1 --- europe 2000/03/04 15:31:08 2000.3 +++ europe 2000/03/08 17:48:59 2000.3.0.1 @@ -1135,6 +1135,12 @@ Link Europe/Rome Europe/San_Marino # 1997-01-21 on transition to Summer time ... established the same order of # daylight savings time settings as in the States of the European Union. +# From Andrei Ivanov (2000-03-06): +# This year Latvia will not switch to Daylight Savings Time (as specified in +# <a href="http://www.lv-laiks.lv/wwwraksti/2000/071072/vd4.htm"> +# The Regulations of the Cabinet of Ministers of the Rep. of Latvia of +# 29-Feb-2000 (#79)</a>, in Latvian for subscribers only). + # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Latvia 1989 1996 - Mar lastSun 2:00s 1:00 S Rule Latvia 1989 1996 - Sep lastSun 2:00s 0 - @@ -1151,7 +1157,8 @@ Zone Europe/Riga 1:36:24 - LMT 1880 3:00 Russia MSK/MSD 1989 Mar lastSun 2:00s 2:00 1:00 EEST 1989 Sep lastSun 2:00s 2:00 Latvia EE%sT 1997 Jan 21 - 2:00 EU EE%sT + 2:00 EU EE%sT 2000 Feb 29 + 2:00 - EET # Liechtenstein # Zone NAME GMTOFF RULES FORMAT [UNTIL] @@ -1178,6 +1185,11 @@ Zone Europe/Vaduz 0:38:04 - LMT 1894 Jun # motion to give up shifting to summer time in spring, as it was # already done by Estonia. +# From Andrei Ivanov (2000-03-06): +# I've heard that Ministers of three Baltic countries on their summit +# somewhere in February decided not to switch to summer time starting from +# this spring. + # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Vilnius 1:41:16 - LMT 1880 1:24:00 - WMT 1917 # Warsaw Mean Time @@ -1192,7 +1204,8 @@ Zone Europe/Vilnius 1:41:16 - LMT 1880 2:00 C-Eur EE%sT 1998 2:00 - EET 1998 Mar 29 1:00u 1:00 EU CE%sT 1999 Oct 31 1:00u - 2:00 EU EE%sT + 2:00 EU EE%sT 2000 Feb + 2:00 - EET # Luxembourg # Whitman disagrees with most of these dates in minor ways; go with Shanks.

5 5

Tomsk wrong timezone
by Jesper Norgaard Welen Feb. 18, 2011

Feb. 18, 2011

A quote from the 'europe' file: # Novosibirskaya oblast'. Zone Asia/Novosibirsk 5:31:40 - LMT 1919 Dec 14 6:00 6:00 - NOVT 1930 Jun 21 # Novosibirsk Time 7:00 Russia NOV%sT 1991 Mar 31 2:00s 6:00 Russia NOV%sT 1992 Jan 19 2:00s 7:00 Russia NOV%sT 1993 May 23 # say Shanks & P. 6:00 Russia NOV%sT # # From Oscar van Vlijmen (2001-08-25): [This region consists of] # Kemerovskaya oblast', Krasnoyarskij kraj, # Tajmyrskij (Dolgano-Nenetskij) avtonomnyj okrug, Tomskaya oblast', # Respublika Tuva, Respublika Khakasiya, Evenkijskij avtonomnyj okrug. Zone Asia/Krasnoyarsk 6:11:20 - LMT 1920 Jan 6 6:00 - KRAT 1930 Jun 21 # Krasnoyarsk Time 7:00 Russia KRA%sT 1991 Mar 31 2:00s 6:00 Russia KRA%sT 1992 Jan 19 2:00s 7:00 Russia KRA%sT In fact, it seems that Tomsk city and Tomskaya oblast' is part of the Novosibirsk timezone, see http://en.wikipedia.org/wiki/Tomskaya_Oblast%27%2C_Russia and http://www.admin.tomsk.ru/1024 ... the latter, if you don't understand russian, look at the time under the green horse. I don't know if this simply means that Tomskaya oblast' changed timezone since 2001, which is a possibility, that would then require a new timezone. 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

3 2

Chinese timezones 1970
by Jesper Norgaard Welen Sept. 14, 2008

Sept. 14, 2008

I have investigated the timezones around 1970 on the http://www.astro.com/atlas site, and here are the results. I am attaching a GIF file of the map I have built based on this information. The red borders are the modern-time administrative borders, while the green lines are the timezone borders I have determined, note that some of them are partially hidden behind the red lines. There are no big surprises. Most timezones follow modern-day administrative boundaries, with the exceptions being Xinjiang, Xizang (Tibet), Qinghai, Gansu, Nei Mongol (Inner Mongolia) and Guangdong. There was an exception in Heliongjiang region on GMT+8.5 where the northern-most county Mohe is on GMT+8. A few other exceptions were two counties on the Sichuan side of the Xizang - Sichuan border, counties Dege and Baiyu which lies on the Sichuan side and are therefore supposed to be GMT+7, Xizang region being GMT+6, but Dege county is GMT+8 according to astro.com while Baiyu county is GMT+6 (could be true), for the moment I am assuming that those two counties are mistakes in the astro.com data. The biggest surprise was that region Guangdong were dived in 3 timezones, a south/west part on GMT+6 (counties Xuwen, Haikang, Suixi, Lianjiang, Zhanjiang, Wuchuan, Huazhou, Gaozhou, Maoming, Dianbai, Xinyi) a central part on GMT+7 (counties Yangchun, Yangjiang, Taishan, Kaiping, Xinxing, Luoding, Yu'nan, Yunfu, Taishan, Deqing and Enping) and a north/east part on GMT+8 with the rest of the counties. Zone Asia/Harbin on GMT+8.5: regions Heilongjiang (minus Mohe) and Jilin. Zone Asia/Shanghai on GMT+8: regions east Nei Mongol, Liaoning, Hebei + Beijing, Shanxi, Shandong, Henan, Jiangsu, Anhui, Shanghai, Zhejiang, Hubei, Hunan, Jiangxi, Fujian, north/east Guangdong and Mohe county of Heilongjiang. Zone Asia/Chongqing on GMT+7: regions west Nei Mongol, Ningxia, Shaanxi, east Gansu, west Qinghai, Sichuan, Guizhou, Guangxi, Yunnan, Hainan island and the central part of Guangdong province. Zone Asia/Urumqi on GMT+6: regions east Xinjiang, west Gansu (counties Dunhuang, Aksay, Anxi, Subei), west Qinghai, east Xizang (Tibet) and east Guangdong. Zone Asia/Kashgar on GMT+5: regions west Xinjiang, west Xizang. 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

4 6

Australia - Broken Hill - Yancowinna
by Oscar van Vlijmen Dec. 15, 2006

Dec. 15, 2006

Broken Hill, or more precise, the whole county of Yancowinna, differs from the rest of New South Wales, as clearly stated in the TZ database. Problem is: what is the "county of Yancowinna"? The Australian Standard Time Act 1987 mentions this county, but doesn't mention the county boundaries. Once they were known, but they have disappeared from recent maps. Finally I found a scan of an old map from the Land Registry, showing the Yancowinna county. Found on the website of The Sydney Morning Herald: <http://www.smh.com.au/articles/2003/08/29/1062050651816.html?oneclick=true> Click on field number 2 or download the map directly: <http://www.smh.com.au/specials/leases/pdf/map2.pdf> The following places are within the county boundaries: Broken Hill, The Gorge, Mount Gipps, Silverton, Stephens Creek, Wahratta, Yanco Glen. The name "Wahratta" is not perfectly readable from the map, but I've checked the name and location against the Australia file from the GEOnet Names Server <http://earth-info.nga.mil/gns/> Oscar van Vlijmen 2005-04-23

4 8

Brazil elections and postponed DST start
by Steffen Thorsen Oct. 4, 2006

Oct. 4, 2006

It is election time in Brazil again, and since it seems that they still cannot handle a time change in the middle of two rounds of election, they are postponing this year's start date to the weekend after the election, 2006-11-05. It appears that the decree is still not published, but that this change is very likely to happen. Source: http://jc.uol.com.br/tvjornal/2006/09/18/not_107666.php (In Portuguese) Auto-translated: It is practically certain that the schedule of summer of this year will start from the zero hour of day 5 of November, in the first turn as weekend after of the elections. Sources of the government had said that already they are finishing the details of the decree that will establish the change in the clocks. Best regards, Steffen Thorsen

2 2

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. 27, 2006

Sept. 27, 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

New country codes: RS, ME
by Mark Davis Sept. 27, 2006

Sept. 27, 2006

There are new country codes RS for Serbia and ME for Montenegro. http://www.iso.org/iso/en/prods-services/iso3166ma/03updates-on-iso-3166/nl… I would suggest the following changes: In zone.tab Change the line: CS +4450+02030 Europe/Belgrade to: RS +4450+02030 Europe/Belgrade Add: ME +4247+01928 Europe/Podgorica In europe Add: Link Europe/Belgrade Europe/Podgorica Mark

2 1

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

Sept. 27, 2006

There is also the original issue of %s being null in 1943. This seems to be a bug. But maybe not. I'm unable from the documents I've seen to determine the intended behavior. None the less, it seems obvious to me that either both the time resulting from the transition and the letter carry forward or neither one does. Have one but not the other carry forward seems nonsensical. ++PLS ________________________________ From: tz-request(a)elsie.nci.nih.gov [mailto:tz-request@elsie.nci.nih.gov] On Behalf Of Mark Davis Sent: Wednesday, September 27, 2006 4:14 PM To: tz(a)lecserver.nci.nih.gov Cc: tz(a)lecserver.nci.nih.gov Subject: Re: Question on abbreviations My reading of the specification (zic.8.txt) was that the first rule mentioned was operative during the interval from 1942 to "only", that is, during 1942 alone. This was by my reading of: TO Gives the final year in which the rule applies. In addition to minimum and maximum (as above), the word only (or an abbreviation) may be used to repeat the value of the FROM field. While it was explained to me what the actual code does, I don't think this is reflected in the above text -- or at least, not at all clearly. According to this text, if I saw the following: Rule US 1942 1944 - Feb 9 2:00 1:00 W # War The rule should not apply in 1945. So I request that the text be fixed, because the rule clearly, according to the explanations given on this thread, applies *afterwards* (and the circumstances in which it applies need to be clearly specified. Is it until the next Rule that has an SAVE value with the same SAVE value as this Rule? Until the next Rule that has a SAVE value?... mark On 9/27/06, Paul Schauble <Paul.Schauble(a)ticketmaster.com> wrote: 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

1 0

Question on abbreviations
by Mark Davis Sept. 27, 2006

Sept. 27, 2006

I'm getting 3 strange cases when parsing the tz database, for the following cases: - Didn't find %s values for M%sT under America/Phoenix:US for 1944 to 1944 - Didn't find %s values for C%sT under Asia/Macau:PRC for 1999 to +INF - Didn't find %s values for CE%sT under Europe/Warsaw:Poland for 1922 to 1940 Let's take the first case. In the file northamerica, we have the following lines. Zone America/Phoenix -7:28:18 - LMT 1883 Nov 18 11:31:42 -7:00 US M%sT 1944 Jan 1 00:01 -7:00 - MST 1944 Apr 1 00:01 -7:00 US M%sT 1944 Oct 1 00:01 -7:00 - MST 1967 -7:00 US M%sT 1968 Mar 21 -7:00 - MST Now, according to my reading of zic.8.txt, to see what the values for %s are, we look at the rules that are in effect for the period in question. So for the 2nd occurence of M%sT, we are concerned with the time between 1944 Apr 1 00:01 UNTIL 1944 Oct 1 00:01, according to the US rules. In the Rule documentation, we have: LETTER/S Gives the "variable part" (for example, the "S" or "D" in "EST" or "EDT") of time zone abbreviations to be used when this rule is in effect. If this field is -, the variable part is null. So to get the value, we should look at the US rule that is in effect during 1944. Here are the US rules: # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule US 1918 1919 - Mar lastSun 2:00 1:00 D Rule US 1918 1919 - Oct lastSun 2:00 0 S Rule US 1942 only - Feb 9 2:00 1:00 W # War Rule US 1945 only - Aug 14 23:00u 1:00 P # Peace Rule US 1945 only - Sep 30 2:00 0 S Rule US 1967 2006 - Oct lastSun 2:00 0 S Rule US 1967 1973 - Apr lastSun 2:00 1:00 D Rule US 1974 only - Jan 6 2:00 1:00 D Rule US 1975 only - Feb 23 2:00 1:00 D Rule US 1976 1986 - Apr lastSun 2:00 1:00 D Rule US 1987 2006 - Apr Sun>=1 2:00 1:00 D Rule US 2007 max - Mar Sun>=8 2:00 1:00 D Rule US 2007 max - Nov Sun>=1 2:00 0 S None of them are operant during 1944, so I don't find any value for M%sT. Am I misreading something? Mark On 9/26/06, Paul Eggert <eggert(a)cs.ucla.edu> wrote: > > Steffen Thorsen <straen(a)thorsen.priv.no> writes: > > > Daylight Saving Time ended Friday for "Rule Palestine" > > Thanks for the heads-up. Here is a proposed patch, which incorporates > the Palestine change along with the other changes already proposed to > this list recently. > > =================================================================== > RCS file: RCS/africa,v > retrieving revision 2006.12 > retrieving revision 2006.12.0.1 > diff -pu -r2006.12 -r2006.12.0.1 > --- africa 2006/09/18 16:58:11 2006.12 > +++ africa 2006/09/20 19:35:29 2006.12.0.1 > @@ -212,35 +212,13 @@ Rule Egypt 1990 1994 - > May 1 1:00 1:00 > # Go with IATA starting in 1995, except correct 1995 entry from 09-30 to > 09-29. > Rule Egypt 1995 max - Apr lastFri 0:00s 1:00 S > Rule Egypt 1995 2005 - Sep lastThu 23:00s 0 - > -# From Hammad Hassan (2006-09-13), quoting The Egyptian Gazette > (2006-09-10), > -# issue no. 41,083, page 1, column 1: > -# Egypt will switch back to the winter time on the eve of the first day > of > -# the Muslim holy month of Ramadan, expected to start this year on Sept. > 24.... > -# "Clocks will be turned back starting from the night on which Darul Ifta > ... > -# announces sighting the crescent of the month of Ramadan,..." Magdi > Radi, > -# the Cabinet spokesman, said yesterday. > -# From Hammad Hassan (2006-09-17): > -# when we reach 1:00AM at Sep 25 the clocks will be turned back to > 12:00AM. > -# I think also this change will be this year and may be the next couple > of > -# years only. (They just want to exclude Ramadan from the summer time; > if > -# so, the change will be among 3 years only if my calculations are > correct). > -# From Paul Eggert (2006-09-17): > -# For now, assume a similar rule will be followed in 2006/2008, and that > -# Ramadan will start as predicted by GNU Emacs 21.4. Here's the code > used > -# to generate the 2006/2008 lines: > -# (let ((year 1427)) > -# (while (< year (+ 1427 3)) > -# (let ((date (calendar-gregorian-from-absolute > -# (calendar-absolute-from-islamic (list 9 2 year))))) > -# (insert (format "Rule\tEgypt\t%d\tonly\t-\t%s\t%2d\t 1:00\t0\t-\n" > -# (extract-calendar-year date) > -# (calendar-month-name (extract-calendar-month date) > 3) > -# (extract-calendar-day date)))) > -# (setq year (1+ year))))) > -Rule Egypt 2006 only - Sep 25 1:00 0 - > -Rule Egypt 2007 only - Sep 14 1:00 0 - > -Rule Egypt 2008 only - Sep 3 1:00 0 - > -Rule Egypt 2009 max - Sep lastThu 23:00s 0 - > +# From Steffen Thorsen (2006-09-19): > +# The Egyptian Gazette, issue 41,090 (2006-09-18), page 1, reports: > +# Egypt will turn back clocks by one hour at the midnight of Thursday > +# after observing the daylight saving time since May. > +# http://news.gom.com.eg/gazette/pdf/2006/09/18/01.pdf > +Rule Egypt 2006 only - Sep 21 23:00s 0 - > +Rule Egypt 2007 max - Sep lastThu 23:00s 0 - > > # Zone NAME GMTOFF RULES FORMAT [UNTIL] > Zone Africa/Cairo 2:05:00 - LMT 1900 Oct > =================================================================== > RCS file: RCS/asia,v > retrieving revision 2006.11 > retrieving revision 2006.11.0.3 > diff -pu -r2006.11 -r2006.11.0.3 > --- asia 2006/08/28 16:18:48 2006.11 > +++ asia 2006/09/26 17:55:21 2006.11.0.3 > @@ -1476,6 +1476,15 @@ Zone Asia/Karachi 4:28:12 - LMT > 1907 > # Gaza changed as well, but presumed Gaza to follow the same rules as > # the West Bank. > > +# From Steffen Thorsen (2006-09-26): > +# according to the Palestine News Network (2006-09-19): > +# > http://english.pnn.ps/index.php?option=com_content&task=view&id=596&Itemid=5 > +# > The Council of Ministers announced that this year its winter schedule > +# > will begin early, as of midnight Thursday. It is also time to turn > +# > back the clocks for winter. Friday will begin an hour late this > week. > +# I guess it is likely that next year's date will be moved as well, > +# because of the Ramadan. > + > # The rules for Egypt are stolen from the `africa' file. > # Rule > NAME FROM TO TYPE IN ON AT SAVE LETTER/S > Rule EgyptAsia 1957 only - May 10 0:00 1:00 S > @@ -1488,8 +1497,10 @@ Rule EgyptAsia 1966 only - > Oct 1 3:00 0 > Rule Palestine 1999 2005 - Apr Fri>=15 0:00 1:00 S > Rule Palestine 1999 2003 - Oct Fri>=15 0:00 0 - > Rule Palestine 2004 only - Oct 1 1:00 0 - > -Rule Palestine 2005 max - Oct 4 2:00 0 - > +Rule Palestine 2005 only - Oct 4 2:00 0 - > Rule Palestine 2006 max - Apr 1 0:00 1:00 S > +Rule Palestine 2006 only - Sep 22 0:00 0 - > +Rule Palestine 2007 max - Oct Fri>=15 0:00 0 - > > # Zone NAME GMTOFF RULES FORMAT [UNTIL] > Zone Asia/Gaza 2:17:52 - LMT 1900 Oct > @@ -1668,11 +1679,18 @@ Rule Syria 1993 only - Sep > 25 0:00 0 - > # IATA SSIM (1998-02) says 1998-04-02; > # (1998-09) says 1999-03-29 and 1999-09-29; (1999-02) says 1999-04-02, > # 2000-04-02, and 2001-04-02; (1999-09) says 2000-03-31 and 2001-03-31; > -# ignore all these claims and go with Shanks & Pottenger. > +# (2006) says 2006-03-31 and 2006-09-22; > +# for now ignore all these claims and go with Shanks & Pottenger, > +# except for the 2006-09-22 claim (which seems right for Ramadan). > Rule Syria 1994 1996 - Apr 1 0:00 1:00 S > -Rule Syria 1994 max - Oct 1 0:00 0 - > +Rule Syria 1994 2005 - Oct 1 0:00 0 - > Rule Syria 1997 1998 - Mar lastMon 0:00 1:00 S > Rule Syria 1999 max - Apr 1 0:00 1:00 S > +# From Stephen Colebourne (2006-09-18): > +# According to IATA data, Syria will change DST on 21st September [21:00 > UTC] > +# this year [only].... This is probably related to Ramadan, like Egypt. > +Rule Syria 2006 only - Sep 22 0:00 0 - > +Rule Syria 2007 max - Oct 1 0:00 0 - > # Zone NAME GMTOFF RULES FORMAT [UNTIL] > Zone Asia/Damascus 2:25:12 - LMT 1920 # Dimashq > 2:00 Syria EE%sT > =================================================================== > RCS file: RCS/southamerica,v > retrieving revision 2006.3 > retrieving revision 2006.3.0.2 > diff -pu -r2006.3 -r2006.3.0.2 > --- southamerica 2006/04/03 14:07:15 2006.3 > +++ southamerica 2006/09/20 19:35:02 2006.3.0.2 > @@ -1064,6 +1064,10 @@ Rule Uruguay 2005 only - Mar > 27 2:00 0 > # 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 - > +# From Jesper Norgaard Welen (2006-09-06): > +# > 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 >

3 4

DST ended early in Palestine
by Steffen Thorsen Sept. 26, 2006

Sept. 26, 2006

Daylight Saving Time ended Friday for "Rule Palestine" according to the Palestine News Network on 2006-09-19: http://english.pnn.ps/index.php?option=com_content&task=view&id=596&Itemid=5 > The Council of Ministers announced that this year its winter schedule > will begin early, as of midnight Thursday. It is also time to turn > back the clocks for winter. Friday will begin an hour late this week. I guess it is likely that next year's date will be moved as well, because of the Ramadan. Best regards, Steffen Thorsen

2 1

FW: update zonerules for Brazil
by Olson, Arthur David (NIH/NCI) [E] Sept. 26, 2006

Sept. 26, 2006

Reinald Verheij is not on the time zone mailing list; direct replies appropriately. --ado ________________________________ From: Reinald Verheij [mailto:reinald.verheij@infor.com] Sent: Tuesday, September 26, 2006 4:42 AM To: tz(a)lecserver.nci.nih.gov Cc: Roelco Rens Subject: update zonerules for Brazil Hi, I understood that Brazil will enter DST at November 5 0:00 2006. This is because of elections (just like 2002). The timezone rules say "first Sunday on or after october 15". So there is a mismatch. Is there an update available for the zonerules for Brazil? I did not find it on the ftp site of elsie.nci.nih.gov. Reinald Verheij Infor

2 1

update zonerules for Brazil
by Reinald Verheij Sept. 26, 2006

Sept. 26, 2006

Hi, I understood that Brazil will enter DST at November 5 0:00 2006. This is because of elections (just like 2002). The timezone rules say "first Sunday on or after october 15". So there is a mismatch. Is there an update available for the zonerules for Brazil? I did not find it on the ftp site of elsie.nci.nih.gov. Reinald Verheij Infor

1 0

Egyptian time change?
by Olson, Arthur David (NIH/NCI) [E] Sept. 25, 2006

Sept. 25, 2006

What's the report from folks on the ground in Egypt as to when clocks were changed? --ado

2 1

FW: tz database in XML format
by Olson, Arthur David (NIH/NCI) [E] Sept. 25, 2006

Sept. 25, 2006

Chuck Salvo has now been added to the time zone mailing list. --ado -----Original Message----- From: Chuck Salvo [mailto:csalvo@salvographics.com] Sent: Friday, September 22, 2006 12:55 PM To: tz(a)lecserver.nci.nih.gov Subject: tz database in XML format There an an XML version of the tz database available here: http://www.salvographics.com/TzDatabase.aspx This may be more useful for porting to non-Posix systems or importing into a database. (The version used is: tzdata2006l.)

1 0

tz database in XML format
by Chuck Salvo Sept. 22, 2006

Sept. 22, 2006

There an an XML version of the tz database available here: http://www.salvographics.com/TzDatabase.aspx This may be more useful for porting to non-Posix systems or importing into a database. (The version used is: tzdata2006l.)

1 0

proposed tz data changes for Syria, Uruguay
by Paul Eggert Sept. 20, 2006

Sept. 20, 2006

Here's the proposed changes to the tz data for today's heads-ups (is that the right word?). Thanks to Stephen Colebourne and Eduardo Cota for these changes. The Syria change takes effect Thursday, so I thought I'd send these out now. =================================================================== RCS file: RCS/asia,v retrieving revision 2006.11 retrieving revision 2006.11.0.1 diff -pu -r2006.11 -r2006.11.0.1 --- asia 2006/08/28 16:18:48 2006.11 +++ asia 2006/09/18 18:57:32 2006.11.0.1 @@ -1670,9 +1670,14 @@ Rule Syria 1993 only - Sep 25 0:00 0 - # 2000-04-02, and 2001-04-02; (1999-09) says 2000-03-31 and 2001-03-31; # ignore all these claims and go with Shanks & Pottenger. Rule Syria 1994 1996 - Apr 1 0:00 1:00 S -Rule Syria 1994 max - Oct 1 0:00 0 - +Rule Syria 1994 2005 - Oct 1 0:00 0 - Rule Syria 1997 1998 - Mar lastMon 0:00 1:00 S Rule Syria 1999 max - Apr 1 0:00 1:00 S +# From Stephen Colebourne (2006-09-18): +# According to IATA data, Syria will change DST on 21st September this +# year [only].... This is probably related to Ramadan, like Egypt. +Rule Syria 2006 only - Sep 21 0:00 0 - +Rule Syria 2007 max - Oct 1 0:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Damascus 2:25:12 - LMT 1920 # Dimashq 2:00 Syria EE%sT =================================================================== RCS file: RCS/southamerica,v retrieving revision 2006.3 retrieving revision 2006.3.0.1 diff -pu -r2006.3 -r2006.3.0.1 --- southamerica 2006/04/03 14:07:15 2006.3 +++ southamerica 2006/09/18 18:57:32 2006.3.0.1 @@ -1064,6 +1064,10 @@ Rule Uruguay 2005 only - Mar 27 2:00 0 # 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 - +# From Eduardo Cota (2006-09-15): +# 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

3 3

proposed tz data changes for Egypt, Syria, Uruguay (revised)
by Paul Eggert Sept. 20, 2006

Sept. 20, 2006

Here is the latest set of proposed changes for Egypt, Syria, and Uruguay. This supersedes the two messages I sent out earlier on this subject in <http://article.gmane.org/gmane.comp.time.tz/1224> and <http://article.gmane.org/gmane.comp.time.tz/1221>. I'd like to thank Steffen Thorsen, Oscar van Vlijmen, and Jesper Norgaard Welen for reading and correcting the earlier messages. This change affects time stamps within the next 48 hours in Egypt and Syria, so people interested in up-to-date correctness in those regions need to apply this patch soon. =================================================================== RCS file: RCS/africa,v retrieving revision 2006.12 retrieving revision 2006.12.0.1 diff -pu -r2006.12 -r2006.12.0.1 --- africa 2006/09/18 16:58:11 2006.12 +++ africa 2006/09/20 19:35:29 2006.12.0.1 @@ -212,35 +212,13 @@ Rule Egypt 1990 1994 - May 1 1:00 1:00 # Go with IATA starting in 1995, except correct 1995 entry from 09-30 to 09-29. Rule Egypt 1995 max - Apr lastFri 0:00s 1:00 S Rule Egypt 1995 2005 - Sep lastThu 23:00s 0 - -# From Hammad Hassan (2006-09-13), quoting The Egyptian Gazette (2006-09-10), -# issue no. 41,083, page 1, column 1: -# Egypt will switch back to the winter time on the eve of the first day of -# the Muslim holy month of Ramadan, expected to start this year on Sept. 24.... -# "Clocks will be turned back starting from the night on which Darul Ifta ... -# announces sighting the crescent of the month of Ramadan,..." Magdi Radi, -# the Cabinet spokesman, said yesterday. -# From Hammad Hassan (2006-09-17): -# when we reach 1:00AM at Sep 25 the clocks will be turned back to 12:00AM. -# I think also this change will be this year and may be the next couple of -# years only. (They just want to exclude Ramadan from the summer time; if -# so, the change will be among 3 years only if my calculations are correct). -# From Paul Eggert (2006-09-17): -# For now, assume a similar rule will be followed in 2006/2008, and that -# Ramadan will start as predicted by GNU Emacs 21.4. Here's the code used -# to generate the 2006/2008 lines: -# (let ((year 1427)) -# (while (< year (+ 1427 3)) -# (let ((date (calendar-gregorian-from-absolute -# (calendar-absolute-from-islamic (list 9 2 year))))) -# (insert (format "Rule\tEgypt\t%d\tonly\t-\t%s\t%2d\t 1:00\t0\t-\n" -# (extract-calendar-year date) -# (calendar-month-name (extract-calendar-month date) 3) -# (extract-calendar-day date)))) -# (setq year (1+ year))))) -Rule Egypt 2006 only - Sep 25 1:00 0 - -Rule Egypt 2007 only - Sep 14 1:00 0 - -Rule Egypt 2008 only - Sep 3 1:00 0 - -Rule Egypt 2009 max - Sep lastThu 23:00s 0 - +# From Steffen Thorsen (2006-09-19): +# The Egyptian Gazette, issue 41,090 (2006-09-18), page 1, reports: +# Egypt will turn back clocks by one hour at the midnight of Thursday +# after observing the daylight saving time since May. +# http://news.gom.com.eg/gazette/pdf/2006/09/18/01.pdf +Rule Egypt 2006 only - Sep 21 23:00s 0 - +Rule Egypt 2007 max - Sep lastThu 23:00s 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Cairo 2:05:00 - LMT 1900 Oct =================================================================== RCS file: RCS/asia,v retrieving revision 2006.11 retrieving revision 2006.11.0.2 diff -pu -r2006.11 -r2006.11.0.2 --- asia 2006/08/28 16:18:48 2006.11 +++ asia 2006/09/20 19:35:02 2006.11.0.2 @@ -1670,9 +1670,14 @@ Rule Syria 1993 only - Sep 25 0:00 0 - # 2000-04-02, and 2001-04-02; (1999-09) says 2000-03-31 and 2001-03-31; # ignore all these claims and go with Shanks & Pottenger. Rule Syria 1994 1996 - Apr 1 0:00 1:00 S -Rule Syria 1994 max - Oct 1 0:00 0 - +Rule Syria 1994 2005 - Oct 1 0:00 0 - Rule Syria 1997 1998 - Mar lastMon 0:00 1:00 S Rule Syria 1999 max - Apr 1 0:00 1:00 S +# From Stephen Colebourne (2006-09-18): +# According to IATA data, Syria will change DST on 21st September [21:00 UTC] +# this year [only].... This is probably related to Ramadan, like Egypt. +Rule Syria 2006 only - Sep 22 0:00 0 - +Rule Syria 2007 max - Oct 1 0:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Damascus 2:25:12 - LMT 1920 # Dimashq 2:00 Syria EE%sT =================================================================== RCS file: RCS/southamerica,v retrieving revision 2006.3 retrieving revision 2006.3.0.2 diff -pu -r2006.3 -r2006.3.0.2 --- southamerica 2006/04/03 14:07:15 2006.3 +++ southamerica 2006/09/20 19:35:02 2006.3.0.2 @@ -1064,6 +1064,10 @@ Rule Uruguay 2005 only - Mar 27 2:00 0 # 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 - +# From Jesper Norgaard Welen (2006-09-06): +# 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

1 0

DST ends earlier than expected in Egypt
by Steffen Thorsen Sept. 19, 2006

Sept. 19, 2006

The Egyptian Gazette, issue 41 090 on 2006-09-18, page 1 now reports that: EGYPT will turn back clocks by one hour at the midnight of Thursday after observing the daylight saving time since May. http://news.gom.com.eg/gazette/pdf/2006/09/18/01.pdf Best regards, Steffen

2 1

FW: Modifications in Uruguay time zone
by Olson, Arthur David (NIH/NCI) [E] Sept. 19, 2006

Sept. 19, 2006

Eduardo Cota is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Eduardo Cota [mailto:cota@fing.edu.uy] Sent: Friday, September 15, 2006 7:33 PM To: tz(a)lecserver.nci.nih.gov Subject: Modifications in Uruguay time zone According to a new decree, from now on, Daylight Saving Time in Uruguay will start the first sunday of october, at 2:00 local time, and will end the second sunday of march at 2:00 local time That is, from the first sunday of october to the second sunday of march, Uruguay will be at UTC-2 You can see it (in spanish) at http://www.presidencia.gub.uy/_web/decretos/2006/09/CM%20210_08%2006%202 006_00001.PDF I think the rules to add to the zoneinfo files would be the following (please correct as necessary) Rule Uruguay 2006 max - Oct Sun>=1 2:00 1:00 S Rule Uruguay 2007 max - Mar Sun>=8 2:00 0 - Yours, Eduardo Cota.

3 2