- tz - lists.iana.org

America/Sao_Paulo DST problem
by Stefano Scarponi May 27, 2004

May 27, 2004

Hi all, During an investigation about customer brazilian problem I downloaded your latest tz lib from "ftp://elsie.nci.nih.gov/pub/". I build and install the library on Linux Redhat 9. I created a simple "my_date.c" that perform a mktime into the range 00:00 - 14 Feb 2004 to 23:59 - 15 Feb 2004. The DST from Brasil Sao_Paulo is the following: file southamerica: Rule Brazil 2000 2001 - Oct Sun>=8 0:00 1:00 S Rule Brazil 2001 max - Feb Sun>=15 0:00 0 - Rule Brazil 2002 only - Nov 3 0:00 1:00 S Rule Brazil 2003 max - Oct Sun>=15 0:00 1:00 S So for the DST about Feb Sun>=15 at 0:00 I expected that the DST occurs at 0:00 15 Feb, but I saw that it occurs at 23:49 14 Feb as you can see from the output program. I set the TZ to TZ=America/Sao_Paulo ./my_date .. .. .. date =<day=14 hours=23 min=45> diff=-60 epoque=1076809501 DST=<1> date =<day=14 hours=23 min=46> diff=-60 epoque=1076809561 DST=<1> date =<day=14 hours=23 min=47> diff=-60 epoque=1076809621 DST=<1> date =<day=14 hours=23 min=48> diff=-60 epoque=1076809681 DST=<1> date =<day=14 hours=23 min=49> diff=-3660 epoque=1076813341 DST=<0> <-------- DST occurs here date =<day=14 hours=23 min=50> diff=-60 epoque=1076813401 DST=<0> date =<day=14 hours=23 min=51> diff=-60 epoque=1076813461 DST=<0> date =<day=14 hours=23 min=52> diff=-60 epoque=1076813521 DST=<0> date =<day=14 hours=23 min=53> diff=-60 epoque=1076813581 DST=<0> date =<day=14 hours=23 min=54> diff=-60 epoque=1076813641 DST=<0> .. .. I think that this is a bug because the DST is for 15 Feb at 0:00 and NOT 23:49 14 Feb. Do you have some suggestions or do you already knows about this problem? This is my "my_date.c" (See attached file: my_date.c) Thanks Stefano

1 0

Now ready: tzcode2004a.tar.gz and tzdata2004a.tar.gz
by Olson, Arthur David (NIH/NCI) May 27, 2004

May 27, 2004

The files... ftp://elsie.nci.nih.gov/pub/tzcode2004a.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tzdata2004a.tar.gz ...are now available. In addition to the proposed changes circulated on the time zone mailing list by Paul Eggert, these include the changes to handle DST transitions that occur at the end of a month in some years but at the start of the following month in other years (these changes were circulated back in March). I've also added a copy of the correspondence that's the basis for claims about DST in the Navajo Nation. --ado

1 0

Re: Beginner questions
by Ruby Ballen May 26, 2004

May 26, 2004

Well, yes. What I was trying to say is if it is possible to do this: - When the user enables automatic DST calculations, use the regular rules. - When the user disables automatic DST calculations, compute local time using the offset that the time zone has when it is in standard time, regardless of DST being in effect or not. It's a desire to have this option, but if it's difficult to achieve it's OK. Thanks tz-request@lecserver. nci.nih.gov To: RBallen(a)hypercom.com cc: tz(a)lecserver.nci.nih.gov 05/26/04 11:21 AM Subject: Beginner questions <<On Wed, 26 May 2004 08:11:51 -0700, Ruby Ballen <RBallen(a)hypercom.com> said: > 2) Is it possible to disable DST changes when using this library? > Say the user wants to move the clock forward/backward manually when > DST is in effect instead of the library doing it for him. This does not make sense. The clock per se is not changed during the DST transition, only the way local time is computed from UTC. -GAWollman

2 1

Beginner questions
by Ruby Ballen May 26, 2004

May 26, 2004

Some questions about this library (please, keep in mind I'm new using it): 1) I was testing localtime() using US/Pacific as time zone and trying to see if transitions to DST were done correctly. So I set my local time to April 4 2004, 1:59 a.m.. Some minutes later the local time was correctly reported as April 4, 3:02. Then, I set my local time to October 31, 1:59 and I double checked that localtime() was in fact giving me 1:59. Two minutes later I was expecting the wall clock to go back one hour. It didn't. What am I doing wrong? 2) Is it possible to disable DST changes when using this library? Say the user wants to move the clock forward/backward manually when DST is in effect instead of the library doing it for him. Thanks a lot for you help. RBallen

3 2

Re: Beginner questions
by Ruby Ballen May 26, 2004

May 26, 2004

It makes sense. Thanks. So if I set it to October 31, 00:59:00 and wait for an hour I should see the transition, right? Thanks a lot. bww(a)acm.org To: RBallen(a)hypercom.com 05/26/04 08:21 AM cc: Subject: Re: Beginner questions > Then, I set my local time to October 31, 1:59 and I double checked > that localtime() was in fact giving me 1:59. Two minutes later I was > expecting the wall clock to go back one hour. It didn't. What am I doing > wrong? There are two 01:59's on that day ... you set the time to the second, after which there is no transition.

1 0

proposed tz changes for Argentina, Mongolia, Mars, etc.
by Paul Eggert May 24, 2004

May 24, 2004

Here are proposed changes to the tz data. The most urgent items are this weekend's emergency law in Mendoza, Argentina, and a correction to the daylight-saving rules in Mongolia, as these changes affect current time stamps. Changes affecting current time stamps: * Mendoza, Argentina moved its clocks back this weekend due to an emergency law designed to save energy. (This is unusual, as normally clocks are moved forward to save energy, but apparently the province uses a lot of electricity in the morning.) Thanks to Mariano Absatz for this item. * Mongolia does observe daylight-saving time. Thanks to Ganbold Ts. for this item. Changes affecting historical time stamps: * Fixes for time stamps before 1901 in Singapore and Kuala Lumpur. Thanks to Mok Ly Yng for this item. * Cuiaba, Brazil used normal Brazilian daylight-saving rules in 1994/1995. (Sorry, I forgot to write down who told me this.) * The names of time zones in Alaska didn't change officially until November 30, 1983, which means Alaska was officially observing "Yukon Time" for most of November 1983. (Thanks to Arthur David Olson for this item.) Administrative change to how hard links are created: * Link the old name "Navajo" to America/Shiprock, not America/Denver. Commentary fixes only: * Quite a bit of commentary added for the hot topic of time and time zones on Mars. * A cross-reference to Cyprus in the `europe' file. * Calcutta is now officially called `Kolkata'. * The Date and Time Gateway has moved from bsdi.com (which no longer exists) to twiki.org. * Joseph Myers's page on time in Britain has moved from student.cusu.cam.ac.uk to www.srcf.ucam.org. * Add URLs pointing to ICU, Joda Time, and Sun Java 1.4. =================================================================== RCS file: RCS/southamerica,v retrieving revision 2003.5 retrieving revision 2003.5.0.1 diff -pu -r2003.5 -r2003.5.0.1 --- southamerica 2003/12/15 14:31:42 2003.5 +++ southamerica 2004/05/24 07:26:59 2003.5.0.1 @@ -141,6 +141,13 @@ Rule Arg 2000 only - Mar Sun>=1 0:00 0 - # This kind of things had always been done this way in Argentina. # We are still -03:00 all year round in all of the country. # +# From Mariano Absatz (2004-05-21): +# Today it was officially published that the Province of Mendoza is changing +# its timezone this winter... starting tomorrow night.... +# http://www.gobernac.mendoza.gov.ar/boletin/pdf/20040521-27158-normas.pdf +# From Paul Eggert (2004-05-24): +# It's Law No. 7,210. This change is due to a public power emergency, so for +# now we'll assume it's for this year only. # # From Paul Eggert (2002-01-22): # <a href="http://www.spicasc.net/horvera.html"> @@ -232,6 +239,8 @@ Zone America/Mendoza -4:35:16 - LMT 1894 -4:00 - WART 1992 Oct 18 -3:00 Arg AR%sT 1999 Oct 3 -4:00 Arg AR%sT 2000 Mar 3 + -3:00 - ART 2004 May 23 + -4:00 - WART 2004 Oct 17 -3:00 - ART # Aruba @@ -389,8 +398,8 @@ Rule Brazil 1992 only - Oct 25 0:00 1:0 Rule Brazil 1993 only - Jan 31 0:00 0 - # Decree <a href="http://pcdsh01.on.br/HV942.htm">942</a> (1993-09-28) # adopted by same states, plus AM. -# Decree <a href="http://pcdsh01.on.br/HV1252.htm">1,252</a> (1994-09-22) -# adopted by same states, minus AM and MT. +# Decree <a href="http://pcdsh01.on.br/HV1252.htm">1,252</a> (1994-09-22; +# web page corrected 2004-01-07) adopted by same states, minus AM. # Decree <a href="http://pcdsh01.on.br/HV1636.htm">1,636</a> (1995-09-14) # adopted by same states, plus MT and TO. # Decree <a href="http://pcdsh01.on.br/HV1674.htm">1,674</a> (1995-10-13) @@ -536,8 +545,6 @@ Zone America/Campo_Grande -3:38:28 - LMT # # Mato Grosso (MT) Zone America/Cuiaba -3:44:20 - LMT 1914 - -4:00 Brazil AM%sT 1994 Sep 22 - -4:00 - AMT 1995 Sep 14 -4:00 Brazil AM%sT 2003 Sep 24 -4:00 - AMT # =================================================================== RCS file: RCS/europe,v retrieving revision 2003.5 retrieving revision 2003.5.0.1 diff -pu -r2003.5 -r2003.5.0.1 --- europe 2003/12/15 14:31:42 2003.5 +++ europe 2004/05/24 07:26:59 2003.5.0.1 @@ -707,6 +707,9 @@ Zone Europe/Sofia 1:33:16 - LMT 1880 # Croatia # see Serbia and Montenegro +# Cyprus +# See the `asia' file. + # Czech Republic # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Czech 1945 only - Apr 8 2:00s 1:00 S =================================================================== RCS file: RCS/asia,v retrieving revision 2003.5 retrieving revision 2003.5.0.1 diff -pu -r2003.5 -r2003.5.0.1 --- asia 2003/12/15 14:31:42 2003.5 +++ asia 2004/05/24 07:26:59 2003.5.0.1 @@ -380,7 +380,7 @@ Zone Asia/Dili 8:22:20 - LMT 1912 # India # Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Asia/Calcutta 5:53:28 - LMT 1880 +Zone Asia/Calcutta 5:53:28 - LMT 1880 # Kolkata 5:53:20 - HMT 1941 Oct # Howrah Mean Time? 6:30 - BURT 1942 May 15 # Burma Time 5:30 - IST 1942 Sep @@ -1012,17 +1012,13 @@ Rule NBorneo 1935 1941 - Sep 14 0:00 0:2 Rule NBorneo 1935 1941 - Dec 14 0:00 0 - # # peninsular Malaysia -# From Paul Eggert (2003-11-01): # The data here are taken from Mok Ly Yng (2003-10-30) # <http://www.math.nus.edu.sg/aslaksen/teaching/timezone.html>. -# Before 1901, Penang, Malacca and Singapore each had their own time zone; -# assume Kuala Lumpur used Malaccan time. # Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Asia/Kuala_Lumpur 6:46:48 - LMT 1880 - 6:49:00 - MMT 1901 Jan 1 # Malacca Mean Time +Zone Asia/Kuala_Lumpur 6:46:46 - LMT 1901 Jan 1 6:55:25 - SMT 1905 Jun 1 # Singapore M.T. 7:00 - MALT 1933 Jan 1 # Malaya Time - 7:00 0:20 MALST 1936 + 7:00 0:20 MALST 1936 Jan 1 7:20 - MALT 1941 Sep 1 7:30 - MALT 1942 Feb 16 9:00 - JST 1945 Sep 12 @@ -1089,6 +1085,15 @@ Zone Indian/Maldives 4:54:00 - LMT 1880 # # [The province of Selenge is omitted from the above lists.] +# From Ganbold Ts., Ulaanbaatar <ganbold(a)micom.mng.net> (2004-04-17): +# Daylight saving occurs at 02:00 local time last Saturday of March. +# It will change back to normal at 02:00 local time last Saturday of +# September.... As I remember this rule was changed in 2001. +# +# From Paul Eggert (2004-04-17): +# For now, assume Rives McDow's informant got confused about Friday vs +# Saturday, and that his 2001 dates should have 1 added to them. + # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Mongol 1983 1984 - Apr 1 0:00 1:00 S Rule Mongol 1983 only - Oct 1 0:00 0 - @@ -1098,8 +1103,9 @@ Rule Mongol 1983 only - Oct 1 0:00 0 - Rule Mongol 1985 1998 - Mar lastSun 2:00s 1:00 S Rule Mongol 1984 1998 - Sep lastSun 2:00s 0 - # IATA SSIM (1999-09) says Mongolia no longer observes DST. -Rule Mongol 2001 only - Apr 27 2:00s 1:00 S -Rule Mongol 2001 only - Sep 28 2:00s 0 - +Rule Mongol 2001 only - Apr lastSat 2:00 1:00 S +Rule Mongol 2001 max - Sep lastSat 2:00 0 - +Rule Mongol 2002 max - Mar lastSat 2:00 1:00 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] # Hovd, a.k.a. Chovd, Dund-Us, Dzhargalant, Khovd, Jirgalanta @@ -1309,10 +1315,10 @@ Zone Asia/Riyadh 3:06:52 - LMT 1950 # The data here are taken from Mok Ly Yng (2003-10-30) # <http://www.math.nus.edu.sg/aslaksen/teaching/timezone.html>. # Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Asia/Singapore 6:55:25 - LMT 1880 +Zone Asia/Singapore 6:55:25 - LMT 1901 Jan 1 6:55:25 - SMT 1905 Jun 1 # Singapore M.T. 7:00 - MALT 1933 Jan 1 # Malaya Time - 7:00 0:20 MALST 1936 + 7:00 0:20 MALST 1936 Jan 1 7:20 - MALT 1941 Sep 1 7:30 - MALT 1942 Feb 16 9:00 - JST 1945 Sep 12 =================================================================== RCS file: RCS/tz-link.htm,v retrieving revision 2003.5 retrieving revision 2003.5.0.1 diff -pu -r2003.5 -r2003.5.0.1 --- tz-link.htm 2003/12/15 14:31:42 2003.5 +++ tz-link.htm 2004/05/24 07:26:59 2003.5.0.1 @@ -9,7 +9,7 @@ <meta http-equiv="Content-type" content='text/html; charset="US-ASCII"' /> <meta name="DC.Creator" content="Eggert, Paul" /> <meta name="DC.Contributor" content="Olson, Arthur David" /> -<meta name="DC.Date" content="2003-09-21" /> +<meta name="DC.Date" content="2004-05-24" /> <meta name="DC.Description" content="Sources of information about time zones and daylight saving time" /> <meta name="DC.Identifier" content="http://www.twinsun.com/tz/tz-link.htm" /> @@ -99,8 +99,8 @@ Here are some recent links that may be o </p> <h2>Web pages using recent versions of the <code>tz</code> database</h2> <ul> -<li><a href="http://www.bsdi.com/date/">Date and Time Gateway</a> is a -text-based point-and-click interface to tables of current time +<li><a href="http://twiki.org/cgi-bin/xtra/tzdate">Date and Time Gateway</a> +is a text-based point-and-click interface to tables of current time throughout the world.</li> <li>Fancier web interfaces, roughly in ascending order of complexity, include: <ul> @@ -157,6 +157,15 @@ href="http://www.perl.com/language/misc/ License</a>. DateTime::TimeZone also contains a script <code>tests_from_zdump</code> that generates test cases for each clock transition in the <code>tz</code> database.</li> +<li><a href="http://oss.software.ibm.com/icu/">International Components for +Unicode (ICU)</a> contains a C/C++ library for internationalization that +has a compiler from <samp>tz</samp> source into an ICU-specific format. +ICU is freely available under a BSD-style license.</li> +<li><a href="http://joda-time.sourceforge.net/">Joda Time - Java date +and time API</a> contains a class +<code>org.joda.time.tz.ZoneInfoCompiler</code> that compiles +<code>tz</code> source into a Joda-specific binary format. Joda Time +is freely available under a BSD-style license.</li> </ul> <h2>Other <code>tz</code> binary file readers</h2> <ul> @@ -177,6 +186,9 @@ under a BSD-style license.</li> </ul> <h2>Other <code>tz</code>-based time zone conversion software</h2> <ul> +<li><a href="http://java.sun.com/">Sun Java</a> releases since 1.4 +contain a copy of a recent <samp>tz</samp> database in a Java-specific +format.</li> <li><a href="http://www1.tip.nl/~t876506/AboutTimeZonesHC.html">HyperCard time zones calculator</a> is a HyperCard stack.</li> @@ -330,7 +342,7 @@ is Singapore in the "Wrong" Time Zone?</ history of legal time in Singapore and Malaysia.</dd> <dt>United Kingdom</dt> <dd><a -href="http://student.cusu.cam.ac.uk/~jsm28/british-time/">History of +href="http://www.srcf.ucam.org/~jsm28/british-time/">History of legal time in Britain</a> discusses in detail the country with perhaps the best-documented history of clock adjustments. The National Physical Laboratory also maintains an <a @@ -362,6 +374,11 @@ among time scales like TAI, TDB, TT and Space Flight - Reference Systems - Time Conventions</a> briefly explains interplanetary space flight timekeeping.</li> <li><a +href="http://www.giss.nasa.gov/tools/mars24/help/notes.html">Technical +Notes on Mars Solar Time as Adopted by the Mars24 Sunclock</a> briefly +describes Mars Coordinated Time (MTC) and the diverse local time +scales used by each landed mission on Mars.</li> +<li><a href="http://hpiers.obspm.fr/eop-pc/products/bulletins/bulletins.html">Bulletins maintained by the IERS EOP (PC)</a> contains official publications of the Earth Orientation Parameters Product Center of the =================================================================== RCS file: RCS/northamerica,v retrieving revision 2003.5 retrieving revision 2003.5.0.1 diff -pu -r2003.5 -r2003.5.0.1 --- northamerica 2003/12/15 14:36:18 2003.5 +++ northamerica 2004/05/24 07:26:59 2003.5.0.1 @@ -193,10 +193,6 @@ Rule US 1987 max - Apr Sun>=1 2:00 1:00 # Samoa standard time # The law doesn't give abbreviations. # -# From Paul Eggert (1995-12-19): -# Shanks uses 1983-10-30, not 1983-11-30, for the 1983 transitions. -# Go with Shanks. -# # From Paul Eggert (2000-01-08), following a heads-up from Rives McDow: # Public law 106-564 (2000-12-23) introduced the abbreviation # "Chamorro Standard Time" for time in Guam and the Northern Marianas. @@ -323,13 +319,14 @@ Zone America/Juneau 15:02:19 - LMT 1867 -8:00 US P%sT 1946 -8:00 - PST 1969 -8:00 US P%sT 1983 Oct 30 2:00 + -9:00 US Y%sT 1983 Nov 30 -9:00 US AK%sT Zone America/Yakutat 14:41:05 - LMT 1867 Oct 18 -9:18:55 - LMT 1900 Aug 20 12:00 -9:00 - YST 1942 -9:00 US Y%sT 1946 -9:00 - YST 1969 - -9:00 US Y%sT 1983 Oct 30 2:00 + -9:00 US Y%sT 1983 Nov 30 -9:00 US AK%sT Zone America/Anchorage 14:00:24 - LMT 1867 Oct 18 -9:59:36 - LMT 1900 Aug 20 12:00 @@ -338,6 +335,7 @@ Zone America/Anchorage 14:00:24 - LMT 1 -10:00 - CAT 1967 Apr -10:00 - AHST 1969 -10:00 US AH%sT 1983 Oct 30 2:00 + -9:00 US Y%sT 1983 Nov 30 -9:00 US AK%sT Zone America/Nome 12:58:21 - LMT 1867 Oct 18 -11:01:38 - LMT 1900 Aug 20 12:00 @@ -346,6 +344,7 @@ Zone America/Nome 12:58:21 - LMT 1867 O -11:00 - NST 1967 Apr -11:00 - BST 1969 -11:00 US B%sT 1983 Oct 30 2:00 + -9:00 US Y%sT 1983 Nov 30 -9:00 US AK%sT Zone America/Adak 12:13:21 - LMT 1867 Oct 18 -11:46:38 - LMT 1900 Aug 20 12:00 @@ -354,6 +353,7 @@ Zone America/Adak 12:13:21 - LMT 1867 O -11:00 - NST 1967 Apr -11:00 - BST 1969 -11:00 US B%sT 1983 Oct 30 2:00 + -10:00 US AH%sT 1983 Nov 30 -10:00 US HA%sT # Shanks writes that part of southwest Alaska (e.g. Aniak) # switched from -11:00 to -10:00 on 1968-09-22 at 02:00, =================================================================== RCS file: RCS/backward,v retrieving revision 2003.4 retrieving revision 2003.4.0.1 diff -pu -r2003.4 -r2003.4.0.1 --- backward 2003/10/06 13:32:20 2003.4 +++ backward 2004/05/24 07:26:59 2003.4.0.1 @@ -65,7 +65,7 @@ Link Africa/Tripoli Libya Link America/Tijuana Mexico/BajaNorte Link America/Mazatlan Mexico/BajaSur Link America/Mexico_City Mexico/General -Link America/Denver Navajo +Link America/Shiprock Navajo Link Pacific/Auckland NZ Link Pacific/Chatham NZ-CHAT Link Pacific/Pago_Pago Pacific/Samoa =================================================================== RCS file: RCS/Theory,v retrieving revision 2003.5 retrieving revision 2003.5.0.1 diff -pu -r2003.5 -r2003.5.0.1 --- Theory 2003/12/15 14:36:34 2003.5 +++ Theory 2004/05/24 07:26:59 2003.5.0.1 @@ -7,6 +7,7 @@ Names of time zone regions Time zone abbreviations Calendrical issues + Time and time zones on Mars ----- Time and date functions ----- @@ -504,3 +505,48 @@ convert to the Gregorian calendar until Source: H. Grotefend, _Taschenbuch der Zeitrechnung des deutschen Mittelalters und der Neuzeit_, herausgegeben von Dr. O. Grotefend (Hannover: Hahnsche Buchhandlung, 1941), pp. 26-28. + + +----- Time and time zones on Mars ----- + +Some people have adjusted their work schedules to fit Mars time. +Dozens of special Mars watches were built for Jet Propulsion +Laboratory workers who kept Mars time during the Mars Exploration +Rovers mission (2004). These timepieces look like normal Seikos and +Citizens but use Mars seconds rather than terrestrial seconds. + +A Mars solar day is called a "sol" and has a mean period equal to +about 24 hours 39 minutes 35.244 seconds in terrestrial time. It is +divided into a conventional 24-hour clock, so each Mars second equals +about 1.02749125 terrestrial seconds. + +The prime meridian of Mars goes through the center of the crater +Airy-0, named in honor of the British astronomer who built the +Greenwich telescope that defines Earth's prime meridian. Mean solar +time on the Mars prime meridian is called Mars Coordinated Time (MTC). + +Each landed mission on Mars has adopted a different reference for +solar time keeping, so there is no real standard for Mars time zones. +For example, the Mars Exploration Rover project (2004) defined two +time zones "Local Solar Time A" and "Local Solar Time B" for its two +missions, each zone designed so that its time equals local true solar +time at approximately the middle of the nominal mission. Such a "time +zone" is not particularly suited for any application other than the +mission itself. + +Many calendars have been proposed for Mars, but none have achieved +wide acceptance. Astronomers often use Mars Sol Date (MSD) which is a +sequential count of Mars solar days elapsed since about 1873-12-29 +12:00 GMT. + +The tz database does not currently support Mars time, but it is +documented here in the hopes that support will be added eventually. + +Sources: + +Michael Allison and Robert Schmunk, +"Technical Notes on Mars Solar Time as Adopted by the Mars24 Sunclock" +<http://www.giss.nasa.gov/tools/mars24/help/notes.html> (2004-03-15). + +Jia-Rui Chong, "Workdays Fit for a Martian", Los Angeles Times +(2004-01-14), pp A1, A20-A21.

1 0

Argentina - Mendoza: Changes
by Mariano Absatz May 21, 2004

May 21, 2004

Hi, well, today it was officially published that the Province of Mendoza is changing its timezone this winter... starting tomorrow night. I'm quite in a hurry, but: At midnight Saturday May 22nd, the clocks will be pulled back one hour (from UTC-03:00 to UTC-04:00). At midnight Saturday October 16th, the clocks will get back to UTC-03:00. The Official data is at http://www.gobernac.mendoza.gov.ar/boletin/pdf/20040521-27158-normas.pdf (in Spanish). Regards. -- Mariano Absatz - El Baby mailto:baby@baby.com.ar http://www.baby.com.ar/ PGP KEYS: http://www.baby.com.ar/datos/personales.html#claves_pgp |\ _ _\\/'> Powered by Pegasus Mail /|__) http://www.pmail.com ) )\ ----------------------------------------------------------- Windows, another fine product from the folks who gave us EDLIN.

1 0

possible changes in Argentina (southamerica)
by Mariano Absatz May 19, 2004

May 19, 2004

Hi, Apparently, the Province of Mendoza, in Argentina's Mid-West, is about to change it's timezone to UTC-04:00 Most of Argentina lies 'geographically' in that tz, but at some point in time, after having implemented UTC-03:00 for the summer, the country 'just stayed there'... what's more, a few years ago, for some time, it used a summer tz of UTC-02:00. As Mendoza is one of the Provinces in the Western border, it is most affected for using a 'more Eastern' tz, and this is especially bad in the (Southern) winter. As there's an Energy crisis in Argentina, Mendoza is trying to 'wake up an hour later'. It remains to be seen if the Province of Mendoza effectively legislates this and what the other Provinces do (especially, the other Provinces in the West). Newspaper info (in Spanish): http://www.lanacion.com.ar/04/05/11/de_600178.asp http://www.clarin.com/diario/2004/05/15/elpais/p-00401.htm http://www1.cronica.com.ar/article/articleview/1084567955/1/20/ http://www.losandes.com.ar/2004/0505/editorial/nota186060_1.htm http://www.losandes.com.ar/2004/0512/economia/nota187333_1.htm I'll keep the list posted as this develops. Regards. -- Mariano Absatz - El Baby mailto:baby@baby.com.ar http://www.baby.com.ar/ PGP KEYS: http://www.baby.com.ar/datos/personales.html#claves_pgp |\ _ _\\/'> Powered by Pegasus Mail /|__) http://www.pmail.com ) )\

2 2

Time zones from Windows XP
by Ruby Ballen May 18, 2004

May 18, 2004

I am new in this mailing list so, please, forgive me if this has been asked before. I'm trying to map the list of time zones that Windows XP includes, to the correct binary files in tz Database, but I am missing some of them. I just could not find which one to use or if it is supported at all. Here is the list: (GMT - 12:00) International Date Line West (GMT - 06:00) Central America (GMT - 03:00) Brasilia (GMT - 02:00) Mid-Atlantic (GMT + 01:00) West Central Africa (GMT + 06:00) Sri Jayawardenepura (GMT + 13:00) Nuku’alofa Also, is there any site where I can find documentation about this library? Thanks a lot for your help. RBallen

3 2

tzdata 2003e: imperfections
by Oscar van Vlijmen May 18, 2004

May 18, 2004

I found a couple of small imperfections in the tzdata files. asia file: Cyprus is now (May 01, 2004) part of the European Union. In spite of the interesting remarks for Cyprus in the tz data file, the Cyprus entry should be in the europe file. antarctica file: New Zealand: Rules are given, but no Zone information, so no actual time information. All files: GMT is obsolete. UTC should be used. Nearly all files, lots of entries: In some cases DST is no longer observed, but the Zone lines still mention a DST Rule. One example from the asia file (some information omitted by me): # Korea (North and South) ... # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule ROK 1960 only - May 15 0:00 1:00 D Rule ROK 1960 only - Sep 13 0:00 0 S Rule ROK 1987 1988 - May Sun<=14 0:00 1:00 D Rule ROK 1987 1988 - Oct Sun<=14 0:00 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Seoul 8:27:52 - LMT 1890 8:30 - KST 1904 Dec 9:00 - KST 1928 8:30 - KST 1932 9:00 - KST 1954 Mar 21 8:00 ROK K%sT 1961 Aug 10 8:30 - KST 1968 Oct 9:00 ROK K%sT ... Since South Korea no longer observes DST, it would be better for the consistency of the database if the last line was changed into: 9:00 ROK K%sT 1988 Oct and an extra line was added, like: 9:00 - KST The software will give the correct time for e.g. this moment I guess, because no Rule line can be found, valid for May 2004. So, changing the database files for this could get a low priority, but it is still an imperfection! Oscar van Vlijmen 2004-05-17

7 11

RE: tzdata 2003e: imperfections (DST rules)
by Olson, Arthur David (NIH/NCI) May 17, 2004

May 17, 2004

> If I am interpreting the documentation correctly, then the last Zone line says that there is a Rule "ROK" in effect, but for dates after Sunday October 09, 1988 no Rule can be found. The last Rule line says that on Sunday October 09, 1988 you should transition out of DST, and that's what the software does. After that, there aren't any transitions specified by Rules, so the software doesn't do anything else. This really is what's supposed to happen; there's no need for a change here. --ado

1 0

Re: tzdata 2003e: imperfections (DST rules)
by Oscar van Vlijmen May 17, 2004

May 17, 2004

> From: "Olson, Arthur David (NIH/NCI)" > Remember that the Rules tell when DST transitions happen; in the above case, > the Rule that's valid is one that specifies the last transition before May > 2004, which is assumed to be in effect in perpetuity. Excerpts from the zic.8 documentation file: " A rule line has the form Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S .... 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. .... The fields that make up a zone line are: Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] .... UNTIL The time at which the UTC offset or the rule(s) change for a location. It is specified as a year, a month, a ..... " The Rule and Zone (continuation) lines from the example are: Rule ROK 1987 1988 - Oct Sun<=14 0:00 0 S Zone... 9:00 ROK K%sT If I am interpreting the documentation correctly, then the last Zone line says that there is a Rule "ROK" in effect, but for dates after Sunday October 09, 1988 no Rule can be found. The DST rules were changed, so, strictly speaking, and according to the documentation, there should be a new Zone line. For users of the TZ software there is no problem I guess, but developers who can only use the database files, encounter minor problems interpreting the database. Oscar van Vlijmen 2004-05-17

1 0

RE: tzdata 2003e: imperfections
by Olson, Arthur David (NIH/NCI) May 17, 2004

May 17, 2004

> 9:00 ROK K%sT > ... > > Since South Korea no longer observes DST, it would be better for the consistency of the database if the last line was changed into: > 9:00 ROK K%sT 1988 Oct > and an extra line was added, like: > 9:00 - KST Generally speaking, we want to have the last line of a Zone refer to a Rule line. This is particularly important in cases where a country has multiple time zones. If the country decides in the future to change the way DST is handled (for example, decides to start observing DST again), we can make things right by changing one Rule rather than by changing multiple Zones. > The software will give the correct time for e.g. this moment I guess, because no Rule line can be found, valid for May 2004. > So, changing the database files for this could get a low priority, but it is still an imperfection! Remember that the Rules tell when DST transitions happen; in the above case, the Rule that's valid is one that specifies the last transition before May 2004, which is assumed to be in effect in perpetuity. --ado

1 0

Change in Mongolian daylight saving time
by Ganbold April 17, 2004

April 17, 2004

Hello, Current rule settings for Mongolia in /usr/src/share/zoneinfo/asia is wrong. It should be changed from: ... Rule Mongol 2001 only - Apr 27 2:00s 1:00 S Rule Mongol 2001 only - Sep 28 2:00s 0 - ... To the following: ... Rule Mongol 2001 only - Mar lastSat 2:00s 1:00 S Rule Mongol 2001 only - Sep lastSat 2:00s 0 - ... Daylight saving occurs at 02:00 local time last Saturday of March. It will changes back to normal at 02:00 local time last Saturday of September. Please make appropriate changes. Please let me know if you have any questions. sincerely, Ganbold Ts. Mongolia

2 5

Mass media article on leap seconds
by Olson, Arthur David (NIH/NCI) April 15, 2004

April 15, 2004

The 2004-03 issue of the U.S. monthly "Discover" has an article titled "Leap Seconds" by Karen Wright(pages 42-45, but the first two pages are décor and an introductory blurb). No mention of the Big Secret (that leap seconds have not been inserted since January of 1999). The article states that "...computer software designers haven't adapted very well to the occasional added second, so experts in air traffic control, satellite communications, and electronic fund transfers have been lobbying to abolish the tinkering. A leap second may have caused the Russian satellite navigation system to crash for hours, and critics claim the added instants could cause commercial airliners to crash as well." The article also notes a couple of modest proposals: "Leap seconds could be inserted every four years along with the February leap day...or leap minutes could be added every half century or so." (Either proposal, if adopted, would require changes in both POSIX and the public-domain time zone code.) Your correspondent's two cents: in setting up the time handling in UNIX, T&R got it exactly right with respect to springing forward and falling back when DST goes in to and out of effect--keep the computer counting monotonically and leave it to the software to translate the monotonic count into a representation of local time. What's right at the level of an hour is also right at the level of a second--keep the computer counting at one count per second, and leave it to software to figure out what should be displayed when the user asks what time it is. --ado

6 8

Re: ICU and "Sources for Time Zone and Daylight Saving Time Data"
by Paul Eggert April 13, 2004

April 13, 2004

"Steven R. Loomis" <srl(a)jtcsv.com> writes: > Java 1.4 has historical time zones (I believe also from the tz > data?) Thanks for letting me know about this. I looked through the source code (in J2SE-1.4.2/java/src.zip) for this. As far as I can tell, the historical time zone data is in J2SE-1.4.2/j2se/jre/lib/zi, in a format that differs somewhat from the standard Olson format. Also, this information is not in every Java 1.4 implementation, though it is in Sun's. I can't find any supported way to convert from tz format to Java format, so if the Java data are wrong there doesn't seem to be any way to update them from the tz master. Does the following snippet summarize this information correctly? <li><a href="http://java.sun.com/">Sun Java</a> releases since 1.4 contain a copy of a recent <samp>tz</samp> database in a Java-specific format.</li>

2 2

ICU and "Sources for Time Zone and Daylight Saving Time Data"
by Paul Eggert April 11, 2004

April 11, 2004

> From: Steven R. Loomis [mailto:srl@jtcsv.com] > Sent: Wednesday, December 03, 2003 8:32 PM > http://oss.software.ibm.com/icu/ Thanks for letting me know about this. Here's a draft description of ICU's use of tz; please let me know of any problems. <li><a href="http://oss.software.ibm.com/icu/">International Components for Unicode (ICU)</a> contains a C/C++ library for internationalization that has a compiler from <samp>tz</samp> source into an ICU-specific format. ICU is freely available under a BSD-style license.</li> By the way do you know about Joda Time? Perhaps you could use it in the Java side of ICU. Here's what I was planning to add for it: <li><a href="http://joda-time.sourceforge.net/">Joda Time - Java date and time API</a> contains a class <code>org.joda.time.tz.ZoneInfoCompiler</code> that compiles <code>tz</code> source into a Joda-specific binary format. Joda Time is freely available under a BSD-style license.</li>

1 0

FW: Update: URL of Time and Date Gateway changed
by Olson, Arthur David (NIH/NCI) April 9, 2004

April 9, 2004

Peter Thoeny is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Peter Thoeny [mailto:peter.thoeny@attglobal.net] Sent: Monday, March 29, 2004 11:37 AM To: tz(a)lecserver.nci.nih.gov Subject: Update: URL of Time and Date Gateway changed Hi, please update the link to "Time and Date Gateway" from http://www.bsdi.com/date to http://TWiki.org/cgi-bin/xtra/tzdate. I am the admin of TWiki.org and inherited the date script from the BSDi folks since their web site is no longer in service. Regards, Peter

3 7

FW: summer / daylight time terminology usage Sydney, AU
by Olson, Arthur David (NIH/NCI) April 5, 2004

April 5, 2004

Darren Blanch is not on the time zone mailing list; direct replies appropriately (and note Darren's request at the end of the message). --ado >From darspam(a)optusnet.com.au Sat Apr 3 05:00:35 2004 Return-Path: <darspam(a)optusnet.com.au> Received: from mail008.syd.optusnet.com.au (mail008.syd.optusnet.com.au [211.29.132.212]) by lecserver.nci.nih.gov (8.12.10/8.12.10) with ESMTP id i33A0X7e005553 for <tz(a)elsie.nci.nih.gov>; Sat, 3 Apr 2004 05:00:34 -0500 (EST) Received: from webmail05.syd.optusnet.com.au (webmail05.syd.optusnet.com.au [211.29.132.239]) by mail008.syd.optusnet.com.au (8.11.6p2/8.11.6) with ESMTP id i33A0Md32146 for <tz(a)elsie.nci.nih.gov>; Sat, 3 Apr 2004 20:00:26 +1000 Message-Id: <200404031000.i33A0Md32146(a)mail008.syd.optusnet.com.au> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) Received: from [211.30.125.100] as user darspam(a)optusnet.com.au by webmail.optusnet.com.au with HTTP; From: darspam(a)optusnet.com.au To: tz(a)lecserver.nci.nih.gov Date: Sat, 03 Apr 2004 20:00:22 +1000 Subject: summer / daylight time terminology usage Sydney, AU Return-Receipt-To: darspam(a)optusnet.com.au Status: RO I found ftp://elsie.nci.nih.gov/pub/ via a reference in rfc2445. The "australasia" document within tzdata2003e.tar.gz made for a specially interesting read. I may be able to add something to the AESD/AEDT/EST/summer/daylight time debate: I am from Sydney, NSW, and have lived there all my life. I distinctly remember from when I was growing up (in the 70s), that people (incl. commercial TV news/weather) used to refer to "EST" for Eastern Standard Time and "DST" for Daylight Savings Time. Weather reports were generally tailored for each city/region so the "Eastern" could be inferred. (This inconsistency disturbed my naturally logical bent, even as a child, which is why I remember it.) However, the phrase "Eastern Summer Time" was also in wide use. These days, AEST and AEDT seem to be widespread, possibly an American influence?? As to the phrase "summer time" versus "daylight time", the locals almost never say "daylight time". Subjectively, I would say that "daylight savings time" is the most common phrase in use, rather than "summer time" (even though the legislation uses "summer time"). Similarly, when talking about start and end dates, we would say "when does daylight savings start?" or "when does daylight saving start?". Note, not "daylight savings time" but "[the practice of] daylight-saving". Regards, Darren R. BLANCH (SN=Blanch,GN=Darren) Blacktown, NSW, Australia dns:darren.blanch.name [Please direct replies to darspam(a)bhsc.nsw.gov.au in addition to darspam(a)optusnet.com.au, since I check the work address more frequently. Also, please don't include my email addresses in any versions of the data file - just "Darren R. Blanch" should suffice if your policies allow.]

1 0

Small correction
by alan＠allm-geodata.com April 4, 2004

April 4, 2004

>From http://www.twinsun.com/tz/tz-link.htm WORLDTIME: interactive atlas, time info, public holidays contains information on local time, sunrise and sunset, and public holidays in several hundred cities around the world. This now comes up with 'The display of holiday information is suspended Best wishes Alan Pritchard The GLOBAL GAZETTEER�: the world on file http://www.allm-geodata.com Tel: +44 (0) 1202 417 477

1 0

Update: URL of Time and Date Gateway changed
by Peter Thoeny March 29, 2004

March 29, 2004

Hi, please update the link to "Time and Date Gateway" from http://www.bsdi.com/date to http://TWiki.org/cgi-bin/xtra/tzdate. I am the admin of TWiki.org and inherited the date script from the BSDi folks since their web site is no longer in service. Regards, Peter

1 0

FW: Mass media article on leap seconds
by Olson, Arthur David (NIH/NCI) March 10, 2004

March 10, 2004

The message below was not forwarded to the list last week since it came from Bradley White's new address; Bradley is now on the list under the new address. --ado ------- Begin Forwarded Message Date: Tue, 02 Mar 2004 12:08:40 -0500 (EST) From: Bradley White <bww(a)acm.org> Subject: Re: Mass media article on leap seconds To: Zone Watchers <tz(a)lecserver.nci.nih.gov> In-Reply-To: Markus' message of Tue, 02 Mar 2004 16:17:48 +0000 ado wrote: > Your correspondent's two cents: in setting up the time handling in UNIX, T&R > got it exactly right with respect to springing forward and falling back when > DST goes in to and out of effect--keep the computer counting monotonically > and leave it to the software to translate the monotonic count into a > representation of local time. What's right at the level of an hour is also > right at the level of a second--keep the computer counting at one count per > second, and leave it to software to figure out what should be displayed when > the user asks what time it is. Markus replied: > I don't agree. There is the important difference that UTC is today very > widely disseminated, whereas TAI is a curiosity only known to time geeks > like us. Keeping a computer synched to something like TAI would only be > practical in the real world if a leap-free timescale (e.g., the existing > TAI or GPS time) were widely enough available, along with a regularly > updated UTC-TAI offset table. Current time distribution services, > however, provide only UTC in easily accessible form, therefore running > machines in TAI would likely cause them to get the leap second offsets > wrong due to out-of-date leap-second tables rather quickly. Their > timestamps would quickly get an integer number of seconds wrong relative > to the timestamps of machines with up-to-date leapsecond tables. I disagree with your disagreement. I ran machines using ado 'right_only' mode and synchronized by NTP, and they sailed smoothly through leaps with no fudging. The NTP code was modified to ignore leap warnings, and to add a single call to time2posix(). If those machines still existed they would still be synchronized no matter whether their leapsecond tables were up- to-date or not (although they would hiccup over leaps they were unaware of). Part of the problem might be in what you refer to as "timestamps". An ado 'right_only' system certainly doesn't believe that its raw time_t is a form useful as an external representation. Bradley ------- End Forwarded Message

1 0

Another tz compiler
by Brian S O'Neill March 3, 2004

March 3, 2004

The main tz project page shows various links to other time zone database formats and other tz compilers. I have been working on the Joda-Time project, which is designed as a replacement for Java's standard date and time classes. It includes a tz compiler and it has its own compact binary format for the resulting files. I would be pleased if the Joda-time project was mentioned on the tz page as well. Joda-Time project: http://joda-time.sourceforge.net/ Compiler (link is unstable): http://joda-time.sourceforge.net/api-0.95/org/joda/time/tz/ZoneInfoCompiler… Most users will have no need to compile the files themselves, as the Joda-Time distribution includes pre-compiled tz files in the jar. The DateTimeZone class knows how to load the files and create objects for them. I finished the tz compiler and new binary format about a year ago. I would have just used Java's standard time zone class, except it did not perform fast enough. Sun's Java v1.4 has a time zone implementation that retrieves offsets using a binary search. Joda-Time's CachedDateTimeZone is faster than a binary search. Caching is handled automatically, and time zones with trivial rules are not wrapped with the cached implementation. It could not be piggybacked onto Java's standard time zone class, as it does not provide a way to iterate over offset transitions. The only documentation on the binary format and the caching is in the source code itself. One of the features in the binary format is that it stores times with variable precision and size. It can store up to millisecond precision, as a 64-bit signed integer. It stores precalculated offset transitions up to the point where a simple DST rule can fully describe all future transitions. Runtime caching is implemented by breaking the time line down into fixed size regions of 2^32 milliseconds, or about 49.7 days. Offset lookup is performed by retrieving one of these regions from the cache. The lookup is performed by shifting out the lower 32 bits of the 64-bit timestamp. This value, modulo 512, is used as an array index to retrieve the region info. A hashtable with 512 regions of 49.7 days provides collision free caching within periods of 69.7 years. The region info object contains a linked list of offset transition instants. Since most regions have less than two transitions, the linked list search is quite fast.

2 2

Re: Mass media article on leap seconds
by Bradley White March 2, 2004

March 2, 2004

ado wrote: > Your correspondent's two cents: in setting up the time handling in UNIX, T&R > got it exactly right with respect to springing forward and falling back when > DST goes in to and out of effect--keep the computer counting monotonically > and leave it to the software to translate the monotonic count into a > representation of local time. What's right at the level of an hour is also > right at the level of a second--keep the computer counting at one count per > second, and leave it to software to figure out what should be displayed when > the user asks what time it is. Markus replied: > I don't agree. There is the important difference that UTC is today very > widely disseminated, whereas TAI is a curiosity only known to time geeks > like us. Keeping a computer synched to something like TAI would only be > practical in the real world if a leap-free timescale (e.g., the existing > TAI or GPS time) were widely enough available, along with a regularly > updated UTC-TAI offset table. Current time distribution services, > however, provide only UTC in easily accessible form, therefore running > machines in TAI would likely cause them to get the leap second offsets > wrong due to out-of-date leap-second tables rather quickly. Their > timestamps would quickly get an integer number of seconds wrong relative > to the timestamps of machines with up-to-date leapsecond tables. I disagree with your disagreement. I ran machines using ado 'right_only' mode and synchronized by NTP, and they sailed smoothly through leaps with no fudging. The NTP code was modified to ignore leap warnings, and to add a single call to time2posix(). If those machines still existed they would still be synchronized no matter whether their leapsecond tables were up- to-date or not (although they would hiccup over leaps they were unaware of). Part of the problem might be in what you refer to as "timestamps". An ado 'right_only' system certainly doesn't believe that its raw time_t is a form useful as an external representation. Bradley

1 0

Proposed change to zic.c and northamerica
by Olson, Arthur David (NIH/NCI) March 2, 2004

March 2, 2004

Getting a jump on DST season, here are proposed minor changes to zic.c and northamerica. The zic.c changes allow rules containing specifications such as... Sun>=25 ...to go past the end of a month; this allows simpler descriptions of the sort of situation that existed in Toronto between 1927 and 1937. Commentary is added to the northamerica file indicating how things could be made simpler, but the data is kept as is to allow folks to continue to use it with pre-2004 versions of zic. (The motive in making the change to zic is to ensure that zic can handle it if some jurisdiction adopts a similar scheme in the future.) --ado ------- zic.c ------- *** /tmp/geta957 Tue Mar 2 10:54:54 2004 --- /tmp/getb957 Tue Mar 2 10:54:55 2004 *************** *** 1,4 **** ! static char elsieid[] = "@(#)zic.c 7.115"; #include "private.h" #include "locale.h" --- 1,4 ---- ! static char elsieid[] = "@(#)zic.c 7.116"; #include "private.h" #include "locale.h" *************** *** 2139,2146 **** --i; } if (i < 0 || i >= len_months[isleap(y)][m]) { ! error(_("no day in month matches rule")); ! (void) exit(EXIT_FAILURE); } } if (dayoff < 0 && !TYPE_SIGNED(time_t)) --- 2139,2146 ---- --i; } if (i < 0 || i >= len_months[isleap(y)][m]) { ! if (noise) ! warning(_("rule goes past start/end of month--will not work with pre-2004 versions of zic")); } } if (dayoff < 0 && !TYPE_SIGNED(time_t)) ------- northamerica ------- *** /tmp/geta975 Tue Mar 2 10:54:55 2004 --- /tmp/getb975 Tue Mar 2 10:54:55 2004 *************** *** 1,4 **** ! # @(#)northamerica 7.67 # also includes Central America and the Caribbean # This data is by no means authoritative; if you think you know better, --- 1,4 ---- ! # @(#)northamerica 7.68 # also includes Central America and the Caribbean # This data is by no means authoritative; if you think you know better, *************** *** 989,994 **** --- 989,1001 ---- # Shanks says 1923-09-19; assume it's a typo and that "-16" was meant. Rule Toronto 1922 1926 - Sep Sun>=15 2:00 0 S Rule Toronto 1924 1927 - May Sun>=1 2:00 1:00 D + # The 1927-to-1939 rules can be expressed more simply as + # Rule Toronto 1927 1937 - Sep Sun>=25 2:00 0 S + # Rule Toronto 1928 1937 - Apr Sun>=25 2:00 1:00 D + # Rule Toronto 1938 1940 - Apr lastSun 2:00 1:00 D + # Rule Toronto 1938 1939 - Sep lastSun 2:00 0 S + # The rules below avoid use of Sun>=25 + # (which pre-2004 versions of zic cannot handle). Rule Toronto 1927 1932 - Sep lastSun 2:00 0 S Rule Toronto 1928 1931 - Apr lastSun 2:00 1:00 D Rule Toronto 1932 only - May 1 2:00 1:00 D

1 0