January 2009 - 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

corrected DST data Switzerland 1941 and 1942, final report
by Alois Treindl Aug. 25, 2011

Aug. 25, 2011

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 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

Coordinates format
by Jonas Melian Feb. 4, 2009

Feb. 4, 2009

Hi, I've seen that is used the format "+-DDMM+-DDDMM" or "+-DDMMSS+-DDDMMSS" to represent latitude and longitude according to ISO-6709 [1] standard. 1) But, the standard is used whith decimals: ±DDMM.MMM ±DDDMM.MMM (degrees and minutes) ±DDMMSS.SS ±DDDMMSS.SS (degrees, minutes and seconds) 2) Could your database to use one only way to represent the format? Or degrees and minutes; or degrees, minutes and seconds. So, the coordinates could be stored as float in the data bases, since that we know its total length. Greetings! [1] http://en.wikipedia.org/wiki/ISO_6709

2 1

FW: Bug in tz code
by Olson, Arthur David (NIH/NCI) [E] Jan. 27, 2009

Jan. 27, 2009

I'm forwarding this message from John Dlugosz, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately. --ado -----Original Message----- From: John Dlugosz [mailto:JDlugosz@TradeStation.com] Sent: Tuesday, January 27, 2009 6:52 To: Olson, Arthur David (NIH/NCI) [E]; tz(a)elsie.nci.nih.gov Subject: RE: Bug in tz code False alarm. I looked at the older "original" output file and find the same result as in my difference list. It seems that the recent "good" file I was comparing with was truncated, some 64 lines and the tail of another line were missing from the end. These should be correct, right? TZ America/Eirunepe differences 1262218281 = 2009-12-30T20:10:57 1262220045 = 2009-12-30T20:40:21 1262221808 = 2009-12-30T21:09:44 1262222979 = 2009-12-30T21:29:15 1262224660 = 2009-12-30T21:57:16 1262225572 = 2009-12-30T22:12:28 1262227105 = 2009-12-30T22:38:01 1262228620 = 2009-12-30T23:03:16 1262230128 = 2009-12-30T23:28:24 1262231594 = 2009-12-30T23:52:50 1262232623 = 2009-12-31T00:09:59 1262233650 = 2009-12-31T00:27:06 1262234850 = 2009-12-31T00:47:06 1262236023 = 2009-12-31T01:06:39 1262237760 = 2009-12-31T01:35:36 1262239235 = 2009-12-31T02:00:11 1262240486 = 2009-12-31T02:21:02 1262242141 = 2009-12-31T02:48:37 1262243457 = 2009-12-31T03:10:33 1262244365 = 2009-12-31T03:25:41 1262245773 = 2009-12-31T03:49:09 1262247497 = 2009-12-31T04:17:53 1262249157 = 2009-12-31T04:45:33 1262250719 = 2009-12-31T05:11:35 1262251681 = 2009-12-31T05:27:37 1262253078 = 2009-12-31T05:50:54 1262254783 = 2009-12-31T06:19:19 1262256067 = 2009-12-31T06:40:43 1262257033 = 2009-12-31T06:56:49 1262257997 = 2009-12-31T07:12:53 1262259265 = 2009-12-31T07:34:01 1262260638 = 2009-12-31T07:56:54 1262261801 = 2009-12-31T08:16:17 1262263054 = 2009-12-31T08:37:10 1262264121 = 2009-12-31T08:54:57 1262265127 = 2009-12-31T09:11:43 1262266871 = 2009-12-31T09:40:47 1262268291 = 2009-12-31T10:04:27 1262269552 = 2009-12-31T10:25:28 1262270480 = 2009-12-31T10:40:56 1262271439 = 2009-12-31T10:56:55 1262272963 = 2009-12-31T11:22:19 1262273928 = 2009-12-31T11:38:24 1262275183 = 2009-12-31T11:59:19 1262276647 = 2009-12-31T12:23:43 1262277614 = 2009-12-31T12:39:50 1262279410 = 2009-12-31T13:09:46 1262280916 = 2009-12-31T13:34:52 1262282596 = 2009-12-31T14:02:52 1262283975 = 2009-12-31T14:25:51 1262285281 = 2009-12-31T14:47:37 1262286458 = 2009-12-31T15:07:14 1262287985 = 2009-12-31T15:32:41 1262289282 = 2009-12-31T15:54:18 1262290422 = 2009-12-31T16:13:18 1262291367 = 2009-12-31T16:29:03 1262293039 = 2009-12-31T16:56:55 1262294198 = 2009-12-31T17:16:14 1262295285 = 2009-12-31T17:34:21 1262296885 = 2009-12-31T18:01:01 1262298068 = 2009-12-31T18:20:44 1262299259 = 2009-12-31T18:40:35 1262300783 = 2009-12-31T19:05:59 1262302548 = 2009-12-31T19:35:24 -----Original Message----- From: Olson, Arthur David (NIH/NCI) [E] [mailto:olsona@dc37a.nci.nih.gov] Sent: Tuesday, January 27, 2009 2:58 PM To: tz(a)elsie.nci.nih.gov Cc: John Dlugosz Subject: RE: Bug in tz code The pre- and post- fencepost fix Eirunepe binary outputs are the same here on the mother ship; is anyone else seeing a glitch? --ado -----Original Message----- From: John Dlugosz [mailto:JDlugosz@TradeStation.com] Sent: Monday, January 26, 2009 8:38 To: Olson, Arthur David (NIH/NCI) [E]; tz(a)lecserver.nci.nih.gov Subject: RE: Bug in tz code ...I'm also getting different output for only times between 2009-12-30T20:00:00 and 2009-12-31T20:00:00 (local time) for America/Eirunepe, which is strange.

1 0

FW: Bug in tz code
by Olson, Arthur David (NIH/NCI) [E] Jan. 27, 2009

Jan. 27, 2009

I'm forwarding this message from John Dlugosz, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately. --ado -----Original Message----- From: John Dlugosz [mailto:JDlugosz@TradeStation.com] Sent: Monday, January 26, 2009 8:38 To: Olson, Arthur David (NIH/NCI) [E]; tz(a)lecserver.nci.nih.gov Subject: RE: Bug in tz code As expected, your change affects the following zones, for dates after the spring of 2475 for: Africa/Cairo America/Godthab Antarctica/Palmer A quick check indicates the expected fix, following DST rules into the future. And I'm also getting different output for only times between 2009-12-30T20:00:00 and 2009-12-31T20:00:00 (local time) for America/Eirunepe, which is strange. --John -----Original Message----- From: Olson, Arthur David (NIH/NCI) [E] [mailto:olsona@dc37a.nci.nih.gov] Sent: Monday, January 26, 2009 3:34 PM To: tz(a)elsie.nci.nih.gov Cc: John Dlugosz Subject: RE: Bug in tz code The America/Godthab problem is a fencepost error; the proposed change below fixes it. --ado ------- zic.c ------- *** /tmp/geta5564 Mon Jan 26 16:26:50 2009 --- /tmp/getb5564 Mon Jan 26 16:26:50 2009 *************** *** 3,9 **** ** 2006-07-17 by Arthur David Olson. */ ! static char elsieid[] = "@(#)zic.c 8.18"; #include "private.h" #include "locale.h" --- 3,9 ---- ** 2006-07-17 by Arthur David Olson. */ ! static char elsieid[] = "@(#)zic.c 8.19"; #include "private.h" #include "locale.h" *************** *** 1995,2001 **** min_year = max_year = EPOCH_YEAR; if (leapseen) { updateminmax(leapminyear); ! updateminmax(leapmaxyear); } for (i = 0; i < zonecount; ++i) { zp = &zpfirst[i]; --- 1995,2001 ---- min_year = max_year = EPOCH_YEAR; if (leapseen) { updateminmax(leapminyear); ! updateminmax(leapmaxyear + (leapmaxyear < INT_MAX)); } for (i = 0; i < zonecount; ++i) { zp = &zpfirst[i];

2 2

FW: Bug in tz code
by Olson, Arthur David (NIH/NCI) [E] Jan. 27, 2009

Jan. 27, 2009

I'm forwarding this message from John Dlugosz, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately. --ado From: John Dlugosz [mailto:JDlugosz@TradeStation.com] Sent: Thursday, January 22, 2009 3:59 To: tz(a)lecserver.nci.nih.gov Subject: Bug in tz code The file America/Godthab, for whatever reason, does not have a POSIX rule string at the end of it. It does have 859 transition times, so far future dates rely on the cyclic behavior of the calendar. However, upon loading, the code does not set the 'goforward' flag. So, in the future (around the year 2409) it does not cycle but uses the last setting indefinitely (WGT) and stops going into daylight savings time (WGST). It was *supposed* to set 'goforward'. But, it did not work. The last entry in ats is 13847763624. So, differ_by_repeat will look for an entry of 1224982824. What is actually in the file is an entry of 1224982823, which is one second too soon to be what is being sought. It broke because differ_by_repeat does not consider leap seconds. The addition of a leap second at the end of 2008 broke it. In order to work properly, zic needs to generate 400 years of table after the last leap second that it used. (But, why didn't it just generate a POSIX rule string like most of the files?) It looks like America/Santiago has the same problem. This might affect all the files that are overly large, and perhaps the lack of POSIX string (and large number of transition times instead) is related to the same issue. --John

2 3

zic files: where is "Indian"?
by John Dlugosz Jan. 26, 2009

Jan. 26, 2009

I have files such as "Indian/Kerguelan", but I can't find that in any of the zic input files. I can't find any mention of "Indian" at all, other than in zone.tab. What am I missing? --John

1 0

Bug in tz code
by John Dlugosz Jan. 22, 2009

Jan. 22, 2009

The file America/Godthab, for whatever reason, does not have a POSIX rule string at the end of it. It does have 859 transition times, so far future dates rely on the cyclic behavior of the calendar. However, upon loading, the code does not set the 'goforward' flag. So, in the future (around the year 2409) it does not cycle but uses the last setting indefinitely (WGT) and stops going into daylight savings time (WGST). It was *supposed* to set 'goforward'. But, it did not work. The last entry in ats is 13847763624. So, differ_by_repeat will look for an entry of 1224982824. What is actually in the file is an entry of 1224982823, which is one second too soon to be what is being sought. It broke because differ_by_repeat does not consider leap seconds. The addition of a leap second at the end of 2008 broke it. In order to work properly, zic needs to generate 400 years of table after the last leap second that it used. (But, why didn't it just generate a POSIX rule string like most of the files?) It looks like America/Santiago has the same problem. This might affect all the files that are overly large, and perhaps the lack of POSIX string (and large number of transition times instead) is related to the same issue. --John

1 0

leapseconds - Bulletin C 37
by Edwin Groothuis Jan. 22, 2009

Jan. 22, 2009

http://hpiers.obspm.fr/eoppc/bul/bulc/bulletinc.dat Bulletin C37 says: NO positive leap second will be introduced at the end of June 2009.

1 0