November 2010 - tz - lists.iana.org

proposed time zone package changes (Samoa, Factory, et al.)
by Arthur David Olson 28 Aug '19

28 Aug '19

Below find proposed time zone package changes; the executive summary: * Makefile Change LOCALTIME default from "Factory" to "GMT"; do not compile "factory" file (but keep it in the distribution). * Theory Remove reference to "Factory" zone. * australasia Change end of DST in Samoa in 2011 from 2011-04-03 0:00 to 2011-04-03 1:00 (thanks to Raymond Hughes for a reference). * localtime.c Initialize ttinfo structures filled by tzparse (thanks to Ravindra for reporting a valgrind warning). * zic.c Fix generation of POSIX strings for zones with rules using "weekday<=n" forms of dates (thanks to Lei Liu for finding the problem). Also, limit output for non-POSIX-specificable zones defined to follow the same rules every year. (Note that no zones of either of the above types appear in the distribution; these changes cater to add-on zones). If no problems are found, 2010n will appear on 2010-10-25. --ado diff -r -c old/Makefile new/Makefile *** old/Makefile Mon Sep 27 09:24:25 2010 --- new/Makefile Tue Oct 12 12:36:50 2010 *************** *** 1,5 **** # <pre> ! # @(#)Makefile 8.8 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. --- 1,5 ---- # <pre> ! # @(#)Makefile 8.9 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. *************** *** 12,18 **** # make zonenames # to get a list of the values you can use for LOCALTIME. ! LOCALTIME= Factory # If you want something other than Eastern United States time as a template # for handling POSIX-style time zone environment variables, --- 12,18 ---- # make zonenames # to get a list of the values you can use for LOCALTIME. ! LOCALTIME= GMT # If you want something other than Eastern United States time as a template # for handling POSIX-style time zone environment variables, *************** *** 262,269 **** DOCS= README Theory $(MANS) date.1 Makefile PRIMARY_YDATA= africa antarctica asia australasia \ europe northamerica southamerica ! YDATA= $(PRIMARY_YDATA) pacificnew etcetera factory backward ! NDATA= systemv SDATA= solar87 solar88 solar89 TDATA= $(YDATA) $(NDATA) $(SDATA) TABDATA= iso3166.tab zone.tab --- 262,269 ---- DOCS= README Theory $(MANS) date.1 Makefile PRIMARY_YDATA= africa antarctica asia australasia \ europe northamerica southamerica ! YDATA= $(PRIMARY_YDATA) pacificnew etcetera backward ! NDATA= systemv factory SDATA= solar87 solar88 solar89 TDATA= $(YDATA) $(NDATA) $(SDATA) TABDATA= iso3166.tab zone.tab diff -r -c old/Theory new/Theory *** old/Theory Mon Sep 27 09:24:25 2010 --- new/Theory Tue Oct 12 12:36:50 2010 *************** *** 1,4 **** ! @(#)Theory 8.4 This file is in the public domain, so clarified as of 2009-05-17 by Arthur David Olson. --- 1,4 ---- ! @(#)Theory 8.5 This file is in the public domain, so clarified as of 2009-05-17 by Arthur David Olson. *************** *** 287,294 **** See the file `backward' for most of these older names (e.g. `US/Eastern' instead of `America/New_York'). The other old-fashioned names still supported are ! `WET', `CET', `MET', `EET' (see the file `europe'), ! and `Factory' (see the file `factory'). ----- Time zone abbreviations ----- --- 287,293 ---- See the file `backward' for most of these older names (e.g. `US/Eastern' instead of `America/New_York'). The other old-fashioned names still supported are ! `WET', `CET', `MET', and `EET' (see the file `europe'). ----- Time zone abbreviations ----- diff -r -c old/australasia new/australasia *** old/australasia Mon Sep 27 09:24:27 2010 --- new/australasia Tue Oct 12 13:14:56 2010 *************** *** 1,5 **** # <pre> ! # @(#)australasia 8.18 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. --- 1,5 ---- # <pre> ! # @(#)australasia 8.19 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. *************** *** 487,497 **** # http://www.parliament.gov.ws/documents/acts/Daylight%20Saving%20Act%20%2020… # </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 2010 Sep 26 ! -11:00 1:00 WSDT 2011 Apr 3 -11:00 - WST # Solomon Is --- 487,507 ---- # http://www.parliament.gov.ws/documents/acts/Daylight%20Saving%20Act%20%2020… # </a> + # From Raymond Hughes (2010-10-07): + # Please see + # <a href="http://www.mcil.gov.ws"> + # http://www.mcil.gov.ws + # </a>, + # the Ministry of Commerce, Industry and Labour (sideframe) "Last Sunday + # September 2010 (26/09/10) - adjust clocks forward from 12:00 midnight + # to 01:00am and First Sunday April 2011 (03/04/11) - adjust clocks + # backwards from 1:00am to 12:00am" + Zone Pacific/Apia 12:33:04 - LMT 1879 Jul 5 -11:26:56 - LMT 1911 -11:30 - SAMT 1950 # Samoa Time -11:00 - WST 2010 Sep 26 ! -11:00 1:00 WSDT 2011 Apr 3 1:00 -11:00 - WST # Solomon Is diff -r -c old/localtime.c new/localtime.c *** old/localtime.c Mon Sep 27 09:24:26 2010 --- new/localtime.c Tue Oct 12 12:36:51 2010 *************** *** 5,11 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 8.14"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 5,11 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 8.15"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 914,919 **** --- 914,920 ---- register unsigned char * typep; register char * cp; register int load_result; + static struct ttinfo zttinfo; INITIALIZE(dstname); stdname = name; *************** *** 986,991 **** --- 987,993 ---- /* ** Two transitions per year, from EPOCH_YEAR forward. */ + sp->ttis[0] = sp->ttis[1] = zttinfo; sp->ttis[0].tt_gmtoff = -dstoffset; sp->ttis[0].tt_isdst = 1; sp->ttis[0].tt_abbrind = stdlen + 1; *************** *** 1099,1106 **** } /* ** Finally, fill in ttis. - ** ttisstd and ttisgmt need not be handled. */ sp->ttis[0].tt_gmtoff = -stdoffset; sp->ttis[0].tt_isdst = FALSE; sp->ttis[0].tt_abbrind = 0; --- 1101,1108 ---- } /* ** Finally, fill in ttis. */ + sp->ttis[0] = sp->ttis[1] = zttinfo; sp->ttis[0].tt_gmtoff = -stdoffset; sp->ttis[0].tt_isdst = FALSE; sp->ttis[0].tt_abbrind = 0; *************** *** 1113,1118 **** --- 1115,1121 ---- dstlen = 0; sp->typecnt = 1; /* only standard time */ sp->timecnt = 0; + sp->ttis[0] = zttinfo; sp->ttis[0].tt_gmtoff = -stdoffset; sp->ttis[0].tt_isdst = 0; sp->ttis[0].tt_abbrind = 0; diff -r -c old/zic.c new/zic.c *** old/zic.c Mon Sep 27 09:24:26 2010 --- new/zic.c Tue Oct 12 13:37:29 2010 *************** *** 3,9 **** ** 2006-07-17 by Arthur David Olson. */ ! static char elsieid[] = "@(#)zic.c 8.22"; #include "private.h" #include "locale.h" --- 3,9 ---- ** 2006-07-17 by Arthur David Olson. */ ! static char elsieid[] = "@(#)zic.c 8.24"; #include "private.h" #include "locale.h" *************** *** 1881,1896 **** register int week; if (rp->r_dycode == DC_DOWGEQ) { ! week = 1 + rp->r_dayofmonth / DAYSPERWEEK; ! if ((week - 1) * DAYSPERWEEK + 1 != rp->r_dayofmonth) return -1; } else if (rp->r_dycode == DC_DOWLEQ) { if (rp->r_dayofmonth == len_months[1][rp->r_month]) week = 5; else { ! week = 1 + rp->r_dayofmonth / DAYSPERWEEK; ! if (week * DAYSPERWEEK - 1 != rp->r_dayofmonth) return -1; } } else return -1; /* "cannot happen" */ (void) sprintf(result, "M%d.%d.%d", --- 1881,1896 ---- register int week; if (rp->r_dycode == DC_DOWGEQ) { ! if ((rp->r_dayofmonth % DAYSPERWEEK) != 1) return -1; + week = 1 + rp->r_dayofmonth / DAYSPERWEEK; } else if (rp->r_dycode == DC_DOWLEQ) { if (rp->r_dayofmonth == len_months[1][rp->r_month]) week = 5; else { ! if ((rp->r_dayofmonth % DAYSPERWEEK) != 0) return -1; + week = rp->r_dayofmonth / DAYSPERWEEK; } } else return -1; /* "cannot happen" */ (void) sprintf(result, "M%d.%d.%d", *************** *** 2018,2023 **** --- 2018,2024 ---- register char * envvar; register int max_abbr_len; register int max_envvar_len; + register int prodstic; /* all rules are min to max */ max_abbr_len = 2 + max_format_len + max_abbrvar_len; max_envvar_len = 2 * max_abbr_len + 5 * 9; *************** *** 2032,2037 **** --- 2033,2039 ---- timecnt = 0; typecnt = 0; charcnt = 0; + prodstic = zonecount == 1; /* ** Thanks to Earl Chew ** for noting the need to unconditionally initialize startttisstd. *************** *** 2053,2058 **** --- 2055,2062 ---- updateminmax(rp->r_loyear); if (rp->r_hiwasnum) updateminmax(rp->r_hiyear); + if (rp->r_lowasnum || rp->r_hiwasnum) + prodstic = FALSE; } } /* *************** *** 2075,2080 **** --- 2079,2094 ---- if (max_year <= INT_MAX - YEARSPERREPEAT) max_year += YEARSPERREPEAT; else max_year = INT_MAX; + /* + ** Regardless of any of the above, + ** for a "proDSTic" zone which specifies that its rules + ** always have and always will be in effect, + ** we only need one cycle to define the zone. + */ + if (prodstic) { + min_year = 1900; + max_year = min_year + YEARSPERREPEAT; + } } /* ** For the benefit of older systems,

5 6

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

Hong Kong problem and BCN timezone(s)
by Jesper Nørgaard 20 Sep '11

20 Sep '11

I have found a small problem in the Hong Kong corrections of 2009q. It seems that the Hong Kong government page says that DST was not used in 1977 and 1978, while this is the current tz data: Rule HK 1965 1977 - Apr Sun>=16 3:30 1:00 S Rule HK 1965 1977 - Oct Sun>=16 3:30 0 - Indeed the whole extract of the government web page is still part of the asia file. I would suggest it should be like this Rule HK 1965 1976 - Apr Sun>=16 3:30 1:00 S Rule HK 1965 1976 - Oct Sun>=16 3:30 0 - My other question concerns the timezone America/Santa_Isabel. It seems that several sources imply that all of Baca California Norte is on the same timezone http://www.frontera.info/EdicionEnlinea/Notas/Noticias/13032010/435414.aspx http://www.notisistema.com/noticias/?p=251578 http://www.timeanddate.com/news/time/north-mexico-dst-change.html This is far from authoritative, but at least and indication that BCN might be one single timezone. I wonder if there has been any confirmation of the Santa Isabel timezone in BCN? I am not saying it is not there, I just haven't found any confirmation of it. - Jesper Norgaard Welen

7 12

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

Can you add permatime.com to the twinsun link page
by Tim Diggins 19 May '11

19 May '11

Hi there - I've been lurking on the list for a while. I don't contribute much as a I'm a (humbly grateful) user of tz information, rather than a provider. I mentioned our http://permatime.com site, a while back, but don't think I explicitly asked for it to go on the twinsun link page under "Web pages using recent versions of the tz database". Can it? http://permatime.com is a service for generating and viewing links that refer to a particular point in time and can be displayed in multiple timezones. It uses the ruby tzinfo gem, based on the Olson Tz database. kind regards Tim http://permatime.com http://teamportfolios.com/permatime Tim Diggins http://red56.co.uk http://tim.teamportfolios.com/

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

FW: Revisiting Australian time zone abbreviations
by Olson, Arthur David (NIH/NCI) [E] 16 Feb '11

16 Feb '11

I'm (trepidatiously) forwarding this message from Richard Stanway, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately. --ado From: Richard Stanway [mailto:r.stanway@gmail.com] Sent: Sunday, June 13, 2010 5:49 To: tz(a)lecserver.nci.nih.gov Subject: Revisiting Australian time zone abbreviations Hello, I came across this mailing list while researching a time zone issue on our website which indirectly makes use of the zoneinfo. We localize some timestamps to the visitors time zone, but the site is trafficked by a predominately US audience where the abbreviation "EST" is used quite often. It is difficult for an Australian visitor to realize that the times they are seeing have been localized since they show for example as "8pm EST" due to the abbreviations used for the Australian time zones, leading to confusion as to whether it is US EST or AU EST. The last discussion on AEST vs EST seems to be about 9 years old and I figured it was time to revisit the subject now that there seems to be an official source. The government website of Australia states the time zone names for Australia are Australian Eastern Standard Time (AEST), Australian Central Standard Time (ACST) and Australian Western Standard Time (AWST) with Australian Eastern Daylight Time (AEDT) and Australian Central Daylight Time (ACDT) when observing daylight saving time. Reference: http://australia.gov.au/about-australia/our-country/time Any chance of these official names making it into a zoneinfo update?

6 5

Re: Future time zone home
by SM 20 Dec '10

20 Dec '10

At 06:11 21-10-10, Olson, Arthur David (NIH/NCI) [E] wrote: >In response to the need to find a new time zone home before I'm >eligible to retire in 2012, Eliot Lear and Paul Eggert have authored >the draft document "IANA Procedures for Maintaining the Timezone >Database" now available from the Internet Engineering Task Force >(IETF) web site: As the intended status of the document is BCP, I'll comment on it from that angle. In Section 1: "Those registries are coordinated by technical experts who are designated by the Internet Engineering Steering Group (IESG)." For what it's worth, some of these registries might not fall under the IESG. In Section 2: 'This list membership will be transitioned to the IETF mail server. The TZ coordinator will continue to manage the list, in accordance with rules of governance for non-WG mailing lists (including, for example, the commonly used "Note Well" statement).' Will the contributions fall under "Note Well" rules? In Section 4: "From time to time it will be necessary to replace a TZ Coordinator. This could occur for a number of reasons:" I suggest "appoint" instead of "replace". "The IESG MUST use rough consensus of the TZ mailing list as their primary guide to further action, when it exists." As the document is a BCP, these requirement could be changed in future. In Section 5: "No change shall be made to the license without consultation and rough consensus of the community." The document uses "rough consensus" instead of consensus". The barrier is lower for the former. The above text mentioned "community". Is that the TZ community? In Section 6: "It is the understanding of the IESG, ISOC, and IANA that the database itself is public domain." I suggest replacing "IESG" with "IETF" as the IESG operates within the IETF. "Should claims be made and substantiated against the database, the IANA will act in accordance with all competent court orders." I suggest putting code distribution under the IETF so that the legal aspect falls under the IETF Trust. The following sentence could then be removed: "Should claims be made and substantiated against the database, the IANA will act in accordance with all competent court orders." I suggest removing "further" from the following sentence: "No further ownership claims will be made by IANA, the IETF Trust, or ISOC on the database." In Section 7: "The IANA will see that the role of TZ Coordinator is filled, based on the procedures described above." According to Section 4, it is the IESG that does that. There is a MoU between IANA and the IETF for IETF protocols. There has been various interpretations of that MoU. An alternative to avoid non-technical concerns is to place the distribution of the database under the RFC Editor and explore having the material with a status similar to the Independent Submission Stream. I am not suggesting a license change. The following text is an adaption from RFC 4846: To the extent that a TZ Contribution or any portion thereof is protected by copyright and other rights of authorship, the Contributor, and each named co-Contributor, and the organization he or she represents or is sponsored by (if any) grant an irrevocable, non-exclusive, royalty-free, world-wide right and license to the IETF Trust and the IETF under all intellectual property rights in the TZ Contribution in perpetuity, to copy, publish, display, and distribute the TZ Contribution. The Contributor, each named co-Contributor, and the organizations represented above irrevocably and in perpetuity grant the rights listed below to the Internet Community: A. to prepare or allow the preparation of translations of the TZ database into languages other than English, B to prepare derivative works (other than translations) that are based on or incorporate all or part of the TZ Contribution, or comment upon it. The license to such derivative works shall not grant the IETF Trust, the IETF, or other party preparing a derivative work any more rights than the license to the original TZ Contribution, and C. to reproduce any trademarks, service marks, or trade names that are included in the TZ Contribution solely in connection with the reproduction, distribution, or publication of the TZ Contribution and derivative works. At 09:09 21-10-10, Tony Finch wrote: >Apart from three files, the current tzcode distribution is public domain. >There is no single BSD licence so this statement is ambiguous. In fact the >licence on the three special files is more like a MIT licence. Yes. Regards, -sm

4 9

Future time zone home
by Olson, Arthur David (NIH/NCI) [E] 16 Dec '10

16 Dec '10

In response to the need to find a new time zone home before I'm eligible to retire in 2012, Eliot Lear and Paul Eggert have authored the draft document "IANA Procedures for Maintaining the Timezone Database" now available from the Internet Engineering Task Force (IETF) web site: http://tools.ietf.org/html/draft-lear-iana-timezone-database-00 Comments on how the draft can be improved are welcome. Also welcome: feedback on whether the proposed approach meets the needs of folks on the time zone mailing list--the proposed approach can't and won't go forward without support from the time zone community. The document includes electronic mail addresses for Eliot and Paul; general comments can also be sent to the time zone mailing list. --ado

6 6

time zone database open questions
by Arthur David Olson 09 Dec '10

09 Dec '10

Here are the open time zone database questions I know of. Are the others? 1. Did all of Mexico's Baja California Norte use United States DST rules in 2010, or did only border areas use U.S. DST? What of other Mexican states on the U.S. border? 2. How was DST handled in the West Bank and in Gaza in 2010? How was it handled in previous years? 3. What's the accurate history of the change to use of Shanghai/Beijing time in China? 4. Is there an acceptable way of handling present-day dual timekeeping in Xinjiang, China without either losing track of past practices? 5. Did Windsor and other parts of Ontario, Canada use different DST rules in the past? (See Mark Brader's communication at the end of this message.) --ado # From Mark Brader (2010-03-06): # ... # In the (Toronto) Globe and Mail for Saturday, 1955-09-24, in the bottom # right corner of page 1, it says that Toronto will return to standard # time at 2 am Sunday morning (which agrees with the database), and that: # # The one-hour setback will go into effect throughout most of Ontario, # except in areas like Windsor which remains on standard time all year. # # Windsor is, of course, a lot larger than Nipigon. # # I only came across this incidentally. I don't know if Windsor began # observing DST when Detroit did, or in 1974, or on some other date. # # By the way, the article continues by noting that: # # Some cities in the United States have pushed the deadline back # three weeks and will change over from daylight saving in October.

4 3