August 2009 - tz - lists.iana.org

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

25 May '15

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

corrected DST data Switzerland 1941 and 1942, final report
by Alois Treindl 25 Aug '11

25 Aug '11

Hello I have researched the DST usage in Switzerland during the 1940ies. As I wrote in an earlier message, I suspected the current tzdata values to be wrong. This is now verified. I have found copies of the original ruling by the Swiss Federal government, in 'Eidgenössische Gesetzessammlung 1941 and 1942' (Swiss federal law collection) and attach GIF copies of the two pages for 1941. DST began on Monday 5 May 1941, 1:00 am by shifting the clocks to 2:00 am DST ended on Monday 6 Oct 1941, 2:00 am by shifting the clocks to 1:00 am. DST began on Monday, 4 May 1942 at 01:00 am DST ended on Monday, 5 Oct 1942 at 02:00 am There was no DST in 1940, I have checked the law collection carefully. It is also indicated by the fact that the 1942 entry in the law collection points back to 1941 as a reference, but no reference to any other years are made. Newspaper articles I have read in the archives on 6 May 1941 reported about the introduction of DST (Sommerzeit in German) during the previous night as an absolute novelty, because this was the first time that such a thing had happened in Switzerland. I have also checked 1916, because one book source (Gabriel, Traite de l'heure dans le monde) claims that Switzerland had DST in 1916. This is false, no official document could be found. Probably Gabriel got misled by references to Germany, which introduced DST in 1916 for the first time. The tzdata rules for Switzerland must be changed to: Rule Swiss 1941 1942 - May Mon>=1 1:00 1:00 S Rule Swiss 1941 1942 - Oct Mon>=1 2:00 0 - The 1940 rules must be deleted. One further detail for Switzerland, which is probably out of scope for most users of tzdata: The zone file Zone Europe/Zurich 0:34:08 - LMT 1848 Sep 12 0:29:44 - BMT 1894 Jun #Bern Mean Time 1:00 Swiss CE%sT 1981 1:00 EU CE%sT describes all of Switzerland correctly, with the exception of the Cantone Geneve (Geneva, Genf). Between 1848 and 1894 Geneve did not follow Bern Mean Time but kept its own local mean time. To represent this, an extra zone would be needed. Two GIF files are attached. best regards Alois -- || Alois Treindl, Astrodienst AG, mailto:alois@astro.com || Zollikon/Zurich, Switzerland || Free astrological charts at http://www.astro.com/ || SWISS EPHEMERIS Free Edition at http://www.astro.com/swisseph/

2 3

Tomsk wrong timezone
by Jesper Norgaard Welen 18 Feb '11

18 Feb '11

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

New home for time zone stuff by 2012?
by Olson, Arthur David (NIH/NCI) [E] 08 Sep '09

08 Sep '09

I'll be eligible to start drawing a pension in mid-2012. Since I'm accustomed to slow-moving Quaker process, that makes it time to get serious about finding a new home for time zone stuff. There are several pieces of the puzzle (some of which haven't seen much work of late): Data maintenance Data distribution Code maintenance Code distribution Mailing list maintenance Mailing list hosting Standards work (for example, tweaking POSIX TZ environment variables so Godthab can be represented) Code enhancement (for example, year zero work and Julian calendar work) There are different types of landing place: Governmental organizations Non-governmental organizations Commercial entities Volunteers Everything could be moved under one new roof or different pieces might go different places. While I'm happy to continue time zone work in the future, I also understand that it may be best for others to do the work. Anyone? Bueller? --ado

26 38

West Bank to end DST on Friday
by Steffen Thorsen 03 Sep '09

03 Sep '09

Palestine’s Council of Ministers announced that they will revert back to winter time on Friday, 2009-09-04. One news source: http://www.safa.ps/ara/?action=showdetail&seid=4158 (Palestinian press agency, Arabic), Google translate: "Decided that the Palestinian government in Ramallah headed by Salam Fayyad, the start of work in time for the winter of 2009, starting on Friday approved the fourth delay Sept. clock sixty minutes per hour as of Friday morning. " We are not sure if Gaza will do the same, last year they had a different end date, we will keep this page updated: http://www.timeanddate.com/news/time/westbank-gaza-dst-2009.html Best regards, Steffen Thorsen - timeanddate.com

2 1

Proposed time zone package changes for West Bank (comment only) and Samoa
by Arthur David Olson 31 Aug '09

31 Aug '09

Below are proposed changes to the "australasia" file to reflect use of DST in Samoa in 2009-2010, as well as a comment added to the "asia" file on DST in the West Bank this year. The Samoa change may need tweaking once the actual legislation (and the hour at which the changes take place) is in hand; there may be a need to tweak the "asia" file once Gaza's DST end in 2009 is determined. If no problems are found, these changes will appear in the ftp packages on 2009-09-07. Some long-term work is needed on the differences between West Bank time and Gaza time. --ado ------- australasia ------- *** /tmp/geta10880 Mon Aug 31 12:25:41 2009 --- /tmp/getb10880 Mon Aug 31 12:25:41 2009 *************** *** 1,5 **** # <pre> ! # @(#)australasia 8.12 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. --- 1,5 ---- # <pre> ! # @(#)australasia 8.13 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. *************** *** 443,452 **** # http://www.worldtimezone.com/dst_news/dst_news_samoa01.html # </a> Zone Pacific/Apia 12:33:04 - LMT 1879 Jul 5 -11:26:56 - LMT 1911 -11:30 - SAMT 1950 # Samoa Time ! -11:00 - WST # Samoa Time # Solomon Is # excludes Bougainville, for which see Papua New Guinea --- 443,468 ---- # http://www.worldtimezone.com/dst_news/dst_news_samoa01.html # </a> + # From Steffen Thorsen (2009-08-27): + # Samoa's parliament passed the Daylight Saving Bill 2009, and will start + # daylight saving time on the first Sunday of October 2009 and end on the + # last Sunday of March 2010. We hope that the full text will be published + # soon, but we believe that the bill is only valid for 2009-2010. Samoa's + # Daylight Saving Act 2009 will be enforced as soon as the Head of State + # executes a proclamation publicizing this Act. + # + # Some background information here, which will be updated once we have + # more details: + # <a href="http://www.timeanddate.com/news/time/samoa-dst-plan-2009.html"> + # http://www.timeanddate.com/news/time/samoa-dst-plan-2009.html + # </a> + Zone Pacific/Apia 12:33:04 - LMT 1879 Jul 5 -11:26:56 - LMT 1911 -11:30 - SAMT 1950 # Samoa Time ! -11:00 - WST 2009 Oct 4 ! -11:00 1:00 WSDT 2010 Mar 28 ! -11:00 - WST # Solomon Is ------- asia ------- *** /tmp/geta10818 Mon Aug 31 12:24:30 2009 --- /tmp/getb10818 Mon Aug 31 12:24:31 2009 *************** *** 1,5 **** # <pre> ! # @(#)asia 8.38 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. --- 1,5 ---- # <pre> ! # @(#)asia 8.39 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. *************** *** 1836,1841 **** --- 1836,1861 ---- # http://www.worldtimezone.com/dst_news/dst_news_westbank01.html # </a> + # From Steffen Thorsen (2009-08-31): + # Palestine's Council of Ministers announced that they will revert back to + # winter time on Friday, 2009-09-04. + # + # One news source: + # <a href="http://www.safa.ps/ara/?action=showdetail&seid=4158"> + # http://www.safa.ps/ara/?action=showdetail&seid=4158 + # </a> + # (Palestinian press agency, Arabic), + # Google translate: "Decided that the Palestinian government in Ramallah + # headed by Salam Fayyad, the start of work in time for the winter of + # 2009, starting on Friday approved the fourth delay Sept. clock sixty + # minutes per hour as of Friday morning." + # + # We are not sure if Gaza will do the same, last year they had a different + # end date, we will keep this page updated: + # <a href="http://www.timeanddate.com/news/time/westbank-gaza-dst-2009.html"> + # http://www.timeanddate.com/news/time/westbank-gaza-dst-2009.html + # </a> + # 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 # excludes Bougainville, for which see Papua New Guinea

1 0

FW: New home for time zone stuff by 2012?
by Olson, Arthur David (NIH/NCI) [E] 28 Aug '09

28 Aug '09

I'm forwarding this message from Mike Douglass, who is on the time zone mailing list now but was not when the message was sent. --ado -----Original Message----- From: Mike Douglass [mailto:douglm@rpi.edu] Sent: Thursday, August 27, 2009 9:56 To: tz(a)lecserver.nci.nih.gov Subject: RE: New home for time zone stuff by 2012? The Calendaring and Scheduling Consortium (CalConnect), through a number of activities over time, has demonstrated an active interest in addressing problems related to timezones for calendaring and scheduling systems for a while. The standards in this space, namely iCalendar, were developed by the Internet Engineering Task Force (IETF). A number of issues have spurred this work within CalConnect, including (but not limited to) the US EDST changes from 2007. As "consumers" of timezone data (rather than "producers" - which relates to the job done by the community represented by this mailing list, tz(a)elsie.nci.nih.gov) we are eager to see a reliable, timely and secure process for handling timezones. In CalConnect's Timezone Technical Committee (TC), we are presently developing a timezone service protocol that will allow for direct updates of client systems, rather than relying on the current process where systems typically get updated via OS upgrades, if at all. As part of this effort, we are also developing a generic timezone description format in XML so that interchange of timezone data can be done efficiently, and so that we can include structured meta-data like KML for boundary information. CalConnect would like to see a formal "standardization" of timezone names with a registry. This issue has been a problem in the iCalendar space where presently it is difficult to rely on a timezone definition with a given name, often resulting in interoperability problems. CalConnect would like to see timezone data passed "by reference" rather than "by value" for efficiency purposes (iCalendar requires that a VTIMEZONE component always be included in the iCalendar data stream when a timezone is referenced by an event). Earlier this year, CalConnect hosted a timezone workshop at one of its face-to-face Roundtables. The primary focus of the workshop was to discuss the problem statement and development of the protocol, data format and registry process. Since then we have also initiated discussions in the IETF on these topics. As "consumers" of timezone data CalConnect feels strongly about the need for these improvements. None of this necessarily impacts the process of "producing" timezone data as carried out by this list's community. Nonetheless, we care greatly about the "production" process because we have to rely on this data. We have informally discussed within the CalConnect Timezone TC what we would like to see for the future of the timezone data. We have not come to any firm conclusions as to the best way forward. Mr. Olson's email, therefore, comes as a timely reminder that this needs to be addressed now. Possible options (as already indicated by Mr. Olson) include: - Moving it to an "open source" location (such as SourceForge, which has been already suggested) - Setting up some kind of open consortium of interested parties to manage timezone data - Moving responsibility to an existing standards body (e.g., the IETF or the Internet Society - ISOC) - Moving responsibility to a government entity (e.g., the UN) Unfortunately, this debate can easily get mired in "politics" rather than technical issues. e.g., who gets to control the data, how is the service paid for, who gets to contribute. At the end of the day, CalConnect favors an approach which results in the least amount of disruption. The open community process developed via this list's community has clearly been a success, and should be considered as a potential model going forward. CalConnect considers tightening up of the security of the timezone data to be essential. Given that many systems rely on the data being produced, we collectively need a secure distribution (i.e. a secure, reliable server, signed data etc). Whilst there have not been any obvious "attacks" against timezone data, one cannot assume there won't be any in the future. This is a propitious time to achieve consensus on the best way to secure the data. This may very well impose additional requirements on hosting the data in the future, e.g., cost of maintaining the server, signing certificates etc). CalConnect looks forward to the discussions on this issue, and would like to hear the thoughts of other members of this community. CalConnect is ready to host another face-to-face timezone workshop, open to all interested parties, at our member meeting in February 2010. Mike Douglass douglm(a)rpi.edu Chair Timezone Technical Committee, on behalf of CalConnect

8 8

Samoa to start DST
by Steffen Thorsen 27 Aug '09

27 Aug '09

Samoa's parliament passed the Daylight Saving Bill 2009, and will start daylight saving time on the first Sunday of October 2009 and end on the last Sunday of March 2010. We hope that the full text will be published soon, but we believe that the bill is only valid for 2009-2010. Samoa's Daylight Saving Act 2009 will be enforced as soon as the Head of State executes a proclamation publicizing this Act. Some background information here, which will be updated once we have more details: http://www.timeanddate.com/news/time/samoa-dst-plan-2009.html Regards, Steffen - timeanddate.com

1 0

RE: New home for time zone stuff by 2012?
by Mike Douglass 27 Aug '09

27 Aug '09

The Calendaring and Scheduling Consortium (CalConnect), through a number of activities over time, has demonstrated an active interest in addressing problems related to timezones for calendaring and scheduling systems for a while. The standards in this space, namely iCalendar, were developed by the Internet Engineering Task Force (IETF). A number of issues have spurred this work within CalConnect, including (but not limited to) the US EDST changes from 2007. As "consumers" of timezone data (rather than "producers" - which relates to the job done by the community represented by this mailing list, tz(a)elsie.nci.nih.gov) we are eager to see a reliable, timely and secure process for handling timezones. In CalConnects Timezone Technical Committee (TC), we are presently developing a timezone service protocol that will allow for direct updates of client systems, rather than relying on the current process where systems typically get updated via OS upgrades, if at all. As part of this effort, we are also developing a generic timezone description format in XML so that interchange of timezone data can be done efficiently, and so that we can include structured meta-data like KML for boundary information. CalConnect would like to see a formal "standardization" of timezone names with a registry. This issue has been a problem in the iCalendar space where presently it is difficult to rely on a timezone definition with a given name, often resulting in interoperability problems. CalConnect would like to see timezone data passed "by reference" rather than "by value" for efficiency purposes (iCalendar requires that a VTIMEZONE component always be included in the iCalendar data stream when a timezone is referenced by an event). Earlier this year, CalConnect hosted a timezone workshop at one of its face-to-face Roundtables. The primary focus of the workshop was to discuss the problem statement and development of the protocol, data format and registry process. Since then we have also initiated discussions in the IETF on these topics. As "consumers" of timezone data CalConnect feels strongly about the need for these improvements. None of this necessarily impacts the process of "producing" timezone data as carried out by this list's community. Nonetheless, we care greatly about the "production" process because we have to rely on this data. We have informally discussed within the CalConnect Timezone TC what we would like to see for the future of the timezone data. We have not come to any firm conclusions as to the best way forward. Mr. Olson's email, therefore, comes as a timely reminder that this needs to be addressed now. Possible options (as already indicated by Mr. Olson) include: - Moving it to an "open source" location (such as SourceForge, which has been already suggested) - Setting up some kind of open consortium of interested parties to manage timezone data - Moving responsibility to an existing standards body (e.g., the IETF or the Internet Society - ISOC) - Moving responsibility to a government entity (e.g., the UN) Unfortunately, this debate can easily get mired in "politics" rather than technical issues. e.g., who gets to control the data, how is the service paid for, who gets to contribute. At the end of the day, CalConnect favors an approach which results in the least amount of disruption. The open community process developed via this list's community has clearly been a success, and should be considered as a potential model going forward. CalConnect considers tightening up of the security of the timezone data to be essential. Given that many systems rely on the data being produced, we collectively need a secure distribution (i.e. a secure, reliable server, signed data etc). Whilst there have not been any obvious "attacks" against timezone data, one cannot assume there wont be any in the future. This is a propitious time to achieve consensus on the best way to secure the data. This may very well impose additional requirements on hosting the data in the future, e.g., cost of maintaining the server, signing certificates etc). CalConnect looks forward to the discussions on this issue, and would like to hear the thoughts of other members of this community. CalConnect is ready to host another face-to-face timezone workshop, open to all interested parties, at our member meeting in February 2010. Mike Douglass douglm(a)rpi.edu Chair Timezone Technical Committee, on behalf of CalConnect

1 0

FW: FW: source file correction for tzdata (egypt end of daylight savings)
by Olson, Arthur David (NIH/NCI) [E] 24 Aug '09

24 Aug '09

I'm forwarding this message from John D. Martin III, who is not on the time zone mailing list. Those of you who are on the time zone mailing list, please direct replies appropriately. John's most recent message seems to indicate that the latest "africa" file has the correct transiton time for Egypt. --ado From: John Martin [mailto:john.d.martin.iii@gmail.com] Sent: Monday, August 24, 2009 11:15 To: Olson, Arthur David (NIH/NCI) [E] Cc: tz(a)elsie.nci.nih.gov Subject: Re: FW: source file correction for tzdata (egypt end of daylight savings) I live in Cairo. The time changed before the month of Ramadan began on Saturday 22 August 2009. The actual date of the change was midnight between Thursday 20 and Friday 21, which was not expected before it was announced by the government this week. Prior to that, it had been expected that we would switch after the Islamic month of Ramadan toward the end of September. The reason for the change is that Muslims here fast (no food, drink, smoking or sex) during daylight hours, so this effectively moves the end of fasting every day an hour earlier. They will likely not continue this past this year, but for the past few years, they have switched the time from DST right before Ramadan for this same reason. The reason that this keeps changing is that the Islamic calendar and the gregorian calendar do not line up. Instead, because the Muslim calendar bases the months on the moon phase, the beginning date for each month (including Ramadan) move earlier each year. Again, this will likely not happen again after this year, but you can never tell. The Egyptian government might choose otherwise. No telling until very close to the date. J -- John D. Martin III john.d.martin.iii(a)gmail.com http://youcantmakemistakes.com +1.269.216.9126 (us) +20.16.558.5960 (eg) On Mon, Aug 24, 2009 at 17:00, Olson, Arthur David (NIH/NCI) [E] <olsona(a)dc37a.nci.nih.gov> wrote: I’m forwarding this message from John D. Martin III, who is not on the time zone mailing list. Those of you who are on the time zone mailing list, please direct replies appropriately. John's message indicates a change at the midnight between Friday, August 21 and Saturday, August 22 while the current "Africa" file indicates a change at the midnight between Thursday, August 20 and Friday, August 21. Is there anyone with boots on the ground in Egypt who can tell us what actually happened last week? --ado From: John Martin [mailto:john.d.martin.iii@gmail.com] Sent: Saturday, August 22, 2009 6:43 To: tz(a)lecserver.nci.nih.gov Subject: source file correction for tzdata (egypt end of daylight savings) I am sending some info about the end of daylight savings time for Egypt in 2009. The line for 2009 for Egypt/Cairo in 'africa' within the tzdata source should read : Rule Egypt 2009 only - Aug 21 23:00s 0 - Rule Egypt 2010 max - Sep lastThu 23:00s 0 - The beginning of Ramadan has been used to determine the switch to standard time. In 2009 the switch occurred on 21 August at midnight or the third Thursday of the month. This will likely revert in 2010 to the standard time in the last week in September. Thanks. J -- John D. Martin III john.d.martin.iii(a)gmail.com http://youcantmakemistakes.com +1.269.216.9126 (us) +20.16.558.5960 (eg)

1 0