- tz - lists.iana.org

Re: tzdata2006n Brazil incorrect fall-back date 2009-mar-01
by Paul Eggert Feb. 8, 2007

Feb. 8, 2007

"Dave O'Callaghan" <daveoc(a)uk.ibm.com> writes: > I have been alerted to this website > http://icu-project.org/trac/ticket/5470 which describes an issue with the > Brazil update in tzdata2006n. > > Is this true? It appears to me to be a problem in the ICU4C's code simpletz.cpp, not in the tz code or data itself, so you should ask whoever wrote simpletz.cpp to fix it. The tz data currently says that the fall-back transition in Brazil in 2009 is the last Sunday in February, which will be 2009-02-22, but the ICU4C (?) code apparently does not handle this case correctly. To some extent this is all academic. Judging by past experience, Brazil most likely will change the rules before 2009 rolls around, so the tz data is just guessing about the 2009 transition.

2 1

DST in the news
by Olson, Arthur David (NIH/NCI) [E] Feb. 5, 2007

Feb. 5, 2007

The 2007-02-01 Washington (DC) Post has a front page story, "Clock's Early Spring Forward May Bring About a Few Falls," covering the impending change in US DST rules and the potential consequences. The story is available from http://www.washingtonpost.com; you'll get to register to view the story. --ado

1 0

Mexico revision
by Jesper Norgaard Welen Feb. 4, 2007

Feb. 4, 2007

I have been revising the pages of the Mexican Congress Library at http://www.cddhcu.gob.mx/bibliot/publica/inveyana/polisoc/horver/capitulo5.h tm about timezone changes since 1921 which is also mentioned in the 'northamerica' file (although without the HTM file mentioned). The aim is to bring tz database up-to-date with this information, which is already used as preferred source to Shanks in the 'northamerica' file. I guess then I don't have to argue why I think these pages should have more priority, but rather I would like to point out their deficiencies too before looking at the actual changes to the tz database that I'm recommending. First of all about completeness, I have serious doubt to that these pages are *all* the official Mexican documents that exist about timezone matters - especially concerning the gap of no decrees between 1948 and 1981. In fact, I believe that these decrees are accurate and were followed, but that likely other decrees have not been included in the list, whether there were 33 year gaps or they were smaller. About dates, it seems that most decrees only have a *publication* date, not an effective date. Here is a summary (I named the decrees A to R to have some reference): Decree, Official Publish Date, Effective Date A: 1921-12-20, 1922-01-01 0:00:00 B: 1923-12-00 C: 1927-06-09 D: 1930-11-15 E: 1931-04-28 F: 1932-01-21, 1932-04-01 G: 1942-04-24 H: 1945-11-12 I: 1948-04-05 J: 1981-12-23 K: 1982-11-02 L: 1988-02-17 M: 1989-03-23 N: 1989-03-30 O: 1996-01-04 P: 1997-08-13 Q: 1998-07-31 R: 1999-03-29 the 'northamerica' file states # Here are the discrepancies between Shanks & Pottenger (S&P) and the MLoC. # (In all cases we go with the MLoC.) # S&P report that Baja was at -8:00 in 1922/1923. # S&P say the 1930 transition in Baja was 1930-11-16. # S&P report no DST during summer 1931. # S&P report a transition at 1932-03-30 23:00, not 1932-04-01. Baja at -8:00 seems unlikely, since decree A only mentions -6:00 and -7:00. That the 1930 transition in Baja was 1930-11-16 sounds perfectly plausible to me, I think we should go with Shanks here, and actually it is quite possible that all changes in Mexico (also America/Mexico_City, America/Chihuahua, America/Hermosillo, America/Mazatlan, and America/Tijuana) should be 1930-11-16. No DST during summer 1931 sounds unlikely, see decree E. However some doubt does arise since the decree talks about 'every year' and beginning 1.st. of April each year, while being published nearly a month later (on 1931-04-28). A transition at 1932-03-30 23:00, 1 day and 1 hour before the decree F stated it should be (in fact one of the only Effective Dates of all these decrees) seems extremely unlikely. I don't have a copy of Shanks and Pottenger, so I can't make corrections accordingly. But I think we should believe more in Shanks than these pages for Effective dates if the changes to timezones (the content) are otherwise matching. Now to the actual changes. I am attaching a full 'northamerica' file (version 2007a changed) for convenient difference checking. # Quintana Roo Zone America/Cancun -5:47:04 - LMT 1922 Jan 1 0:12:56 -6:00 - CST 1981 Dec 23 + -5:00 - E%sT 1996 Jan 4 0:00 + -6:00 Mexico E%sT 1997 Oct 26 2:00 -5:00 Mexico E%sT 1998 Aug 2 2:00 That Cancun went from GMT-6 to GMT-5 (no DST involved) at 1981-12-23 is confirmed in decree J. I'm guessing a little bit above, but we have decree O saying explicitly that there are three zones, and one is "all of the national territory except the two other zones". So definitely Cancun most have been on Mexico City time since this decree took effect (sometime on/after 1996-01-04). Decree P then introduces Cancun on GMT-4 during DST and GMT-5 outside, in the end of the DST period defined in decree O. So I assume a smooth transition where Cancun ended their DST from GMT-6 to GMT-5 by simply not switching back the clock to GMT-6, but continuing with GMT-5 until 1998-04-05 where GMT-4 is introduced (DST). # Campeche, Yucatan Zone America/Merida -5:58:28 - LMT 1922 Jan 1 0:01:32 -6:00 - CST 1981 Dec 23 - -5:00 - EST 1982 Dec 2 + -5:00 - EST 1982 Nov 2 -6:00 Mexico C%sT Decree K has publication date 1982-11-02. Would the above effective date 1982-12-02 just by a typo of some kind? I don't know what Shanks date is, but I assume we have nothing better than to go with the publication date. Correct me if I'm wrong, that is quite possible here. # Coahuila, Durango, Nuevo Leon, Tamaulipas Zone America/Monterrey -6:41:16 - LMT 1921 Dec 31 23:18:44 + -7:00 - MST 1927 Jun 10 23:00 + -6:00 - CST 1930 Nov 15 + -7:00 - MST 1931 May 1 23:00 + -6:00 - CST 1931 Oct + -7:00 - MST 1932 Apr 1 - -6:00 - CST 1981 Dec 23 -6:00 Mexico CST 1988 -6:00 US C%sT 1989 + -6:00 Mexico C%sT 2001 Sep 30 02:00 + -6:00 - CST 2002 Feb 20 -6:00 Mexico C%sT This set of changes, although looking complicated, are really quite simple. We have a specific difference for the above four states in decree L of 1988-02-17 applying US style DST in 1988. But there is no evidence that they were any different than Mexico City before or after that year. In fact having GMT-6 unaltered since 1922 to 1988 seems to me extremely unlikely, for instance decree B says that the states from Baja California Sur and Sonora until Veracruz and Oaxaca (exclusively) are all on GMT-7, while Veracruz, Tamaulipas and Oaxaca (and presumably states to the south and east of those) are on GMT-6. Tamaulipas then consists of an exception here, but since this happened before the cutoff date of 1970, we don't need a new timezone for Tamaulipas. Note that I copy the two lines for years 2001-2002 from the America/Mexico_City timezone, although I don't understand them - what is the difference to just using the last line e.g. GMT-6 with Mexico rule, since 1989? # Baja California Zone America/Tijuana -7:48:04 - LMT 1922 Jan 1 0:11:56 -7:00 - MST 1924 -8:00 - PST 1927 Jun 10 23:00 - -7:00 - MST 1930 Nov 15 + -7:00 - MST 1930 Nov 16 - -8:00 - PST 1931 Apr 1 + -8:00 - PST 1931 May 1 23:00 - -8:00 1:00 PDT 1931 Sep 30 + -8:00 1:00 PDT 1931 Oct -8:00 - PST 1942 Apr 24 First I change effective date from 1930-11-15 to 1930-11-16 as per Shanks in the note above. Then I revert the effective date 1931-04-01 to 1931-05-01 23:00 as in the other timezones, because I think it is unlikely that the change happened before the decree E about the change was published (1931-04-28). Also I think this was set as Apr 1 because that is the date that was specified in the decree E, but for all years, not just 1931. September 30 is quite likely also a misinterpretation of the original decree E. It states that every year DST runs from 1.April till 30.th. of September, but that winter time runs from 1.October to 31.st of March. Clearly what is meant is 1930-09-30 24:00 and not 1930-09-30 0:00, or rather 1930-10-01 0:00. Note there is a typo in a note from Debra Goldsmith where 2:OO should be 2:00, above the Indiana definition. I'm not so happy with the Reuter transcript, quite possibly produced in a hurry in Reuters just around the date of the actual event: # From Reuters (2001-09-04): # Mexico's Supreme Court on Tuesday declared that daylight savings was # unconstitutional in Mexico City, creating the possibility the # capital will be in a different time zone from the rest of the nation # next year.... The Supreme Court's ruling takes effect at 2:00 # a.m. (0800 GMT) on Sept. 30, when Mexico is scheduled to revert to # standard time. "This is so residents of the Federal District are not # subject to unexpected time changes," a statement from the court said. The note about the Supreme Court reinstating the DST rules already established by the president, is amusing but perhaps not too relevant. But that the Supreme Court declared daylight saving (not daylight saving*s*) unconstitutional, is plain wrong. Here is a better source (my translation): http://www.conae.gob.mx/wb/CONAE/CONA_2562_breve_historia_del_h ======= Start of translation ======= The first of February 2001 was published in the official newspaper of the federation the presidential decree to establish DST from the First Sunday of May till the Last Sunday of September (five months) in all of the national territory ... Supported by a telephone inquiry of the 24.th. and 25.th. of February 2001, where 239,437 inhabitants of Mexico City where asked their opinion, the mayor of the capital emitted a decree the 26.th. of February, defining that the capital would not implement DST. Additionally, the 5.th. of March 2001 the mayor put forward a constitutional dispute about the validity of the presidential decree published the 1.st. of February 2001. It was the 4.th. of September 2001 that the Supreme Court decided that it was the responsibility of the Congress to determine laws about GMT offset and DST. Congress then approved the current law of DST published in the Official Newspaper 29.th. of December 2001. Finally the 1.st. of March 2002 was published the law about DST during 7 months which is applied each year in Mexico. ======= End of translation ======= In short, the presidential decree was deemed unconstitutional, not daylight saving. Something not mentioned above was that the mayor's decree about setting the time for the capital, was also deemed unconstitutional, in effect a "draw" between the two combattants - it was all about power, of course. The presidential decrees had been a tradition since 1917. But an unconstitutional one, it seems. Regards, - Jesper Nørgaard Welen

1 0

UK news: another attempt to change the clocks likely to fail
by Peter Ilieve Feb. 3, 2007

Feb. 3, 2007

Another attempt to get a bill passed in the UK parliament to move the clocks forward an hour all year got quite a bit of publicity last week. Tim Yeo, a fairly senior figure who has been an environment minister in the past, drew second place in the ballot for private members bills. No doubt mindful of the topicality of climate change, he called his attempt to move the clocks forward an hour the Energy Saving (Daylight) Bill rather than promising extra daylight. The Bill came up for second reading (the first real debate) last Friday, 26 January. It passed a vote (doing much better than Nigel Beard's 2004 attempt) but there weren't enough MPs present for the vote to count for anything. That resulted in the debate being adjourned until tomorrow (2 Feb), but the procedure is such that it is now extremely unlikely to make further progress. The Bill is similar to Nigel Beard's one. It would advance the clocks in England by an hour all year and allow Scotland, Wales and Northern Ireland to decide whether to follow suit or not. The main difference is that it would do this for a trial period, 2008 to 2011, and a review panel would be established to report on this trial. The best place to start for details of this is <http://bills.parliament.uk/DH.asp?title=d> That page has links to the Bill, the debates and a research paper about it. There was also a question asked about this in the Lords on 24 Jan, which can be found in the Lords Hansard at <http://www.publications.parliament.uk/pa/ld200607/ldhansrd/text/ 70124-0001.htm#07012469000005> I asked the person responsible for this at the Department of Trade and Industry for the government's view this morning. He said the government oppose this Bill. I said I wished people would stop trying to change the clocks. `You and me both' he said. :-) I'll send an update if the Bill does make progress. Peter Ilieve peter(a)aldie.co.uk

2 1

time zone question
by A. Diamond Feb. 2, 2007

Feb. 2, 2007

Hello, I just downloaded tzdata and tzcode to update some Linux servers. Thank you for maintaining all this info and code. Just out of curiosity, why does NIH maintain this information instead of NIST? Is it just because someone who happened to be at NIH had the initiative to do it when no one else did? Thanks for your work. Andrew Diamond diamond(a)sheprador.com

1 0

FW: Bulletin C number 33
by Olson, Arthur David (NIH/NCI) [E] Feb. 1, 2007

Feb. 1, 2007

-----Original Message----- From: services.iers(a)obspm.fr [mailto:services.iers@obspm.fr] Sent: Thursday, February 01, 2007 9:49 AM To: adresc1(a)hpopa.obspm.fr Subject: Bulletin C number 33 INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE SERVICE DE LA ROTATION TERRESTRE OBSERVATOIRE DE PARIS 61, Av. de l'Observatoire 75014 PARIS (France) Tel. : 33 (0) 1 40 51 22 26 FAX : 33 (0) 1 40 51 22 91 Internet : services.iers(a)obspm.fr Paris, 1 February 2007 Bulletin C 33 To authorities responsible for the measurement and distribution of time INFORMATION ON UTC - TAI NO positive leap second will be introduced at the end of June 2007. The difference between Coordinated Universal Time UTC and the International Atomic Time TAI is : from 2006 January 1, 0h UTC, until further notice : UTC-TAI = -33 s Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC, or to confirm that there will be no time step at the next possible date. Daniel GAMBIS Director Earth Orientation Center of IERS Observatoire de Paris, France

1 0

daylight-saving news from UCEI, WA, NZ, WY, TERiX
by Paul Eggert Feb. 1, 2007

Feb. 1, 2007

Some recent news about daylight saving time: Ryan Kellogg and Hendrik Wolff of the University of California Energy Institute have published a paper "Does Extending Daylight Saving Time Save Energy? Evidence from an Australian Experiment", CSEM WP 163 (January 2007) <http://www.ucei.berkeley.edu/PDF/csemwp163.pdf>. Their brief answer is "no". They report that the Australian experiment with DST during the 2000 Olympics did not decrease overall electrical consumption, but it did change usage patterns leading to a higher morning peak load. Western Australian Nationals leader Brendon Gryllis says his party will submit a private member's bill next month, calling for a referendum before October 31 to repeal daylight saving time in Western Australia. Nelson, NZ city councillor Mark Holmes and United Future Party leader Peter Dunne have gathered a petition with 10,000 signatures to extend daylight saving time in New Zealand by three weeks. <http://www.newstalkzb.co.nz/newsdetail1.asp?storyID=110957> The Wyoming Senate's Corporations, Elections and Political Subdivisions Committee voted 3-2 against exempting Wyoming from daylight saving time. In a recent poll 41% of Wyoming's inhabitants want to repeal daylight saving, and 44% want to keep it. <http://www.billingsgazette.net/articles/2007/01/18/news/wyoming/55-time.txt> <http://www.billingsgazette.net/articles/2007/01/17/news/wyoming/38-time.txt> Various companies have announced support for the US daylight-saving time changes in their software, or in older versions of other people's software. My favorite was TERiX, which announced free patches for Solaris 2.5.1 through 2.7, for customers who don't want to bother to run 'zic' themselves.

1 0

Canada (2007)
by Chris Walton Jan. 31, 2007

Jan. 31, 2007

For anybody wishing for info on new Canadian daylight saving legislation, I have been trying to keep the following page up to date: http://www3.sympatico.ca/c.walton/canada_dst.html The web page is full of links to various government news releases and legislation. All of Canada with the possible exception of Nunavut will be extending daylight saving this year to match the United States. Below is an extract of some of the more important hyperlinks from the web page listed above. City of Lloydminster The "Lloydminster Charter" which defines time for the city of Lloydminster on both sides of the Alberta/Saskatchewan border will likely not be amended prior to March 11. Regardless, the Senior Director of Corporate Affairs e-mailed me last year to say that Lloydminster would extend daylight saving to match Alberta. British Columbia News release: http://www2.news.gov.bc.ca/news_releases_2005-2009/2006AG0014-000330.htm Alberta News release: http://www.gov.ab.ca/acn/200602/193862BFE321E-A3D2-C519-F34B3EE936DA55E2.ht… Daylight Saving Amendment Act assented to March 23/2006: http://www.qp.gov.ab.ca/documents/spring/CH03_06.CFM?type=htm Saskatchewan No official announcement but most of Saskatchewan does not observe daylight saving time. The small area outside the Lloydminster city limits is governed by the Saskatchewan Time Act and will most likely follow Lloydminster even if the act is not updated. Manitoba News release: http://www.gov.mb.ca/chc/press/top/2005/11/2005-11-02-06.html Manitoba Official Time Amendment Act assented to December 8/2005: http://web2.gov.mb.ca/laws/statutes/2005/c05305e.php Ontario News release: http://www.attorneygeneral.jus.gov.on.ca/english/news/2005/20051020-dst.asp Ontario Regulation 111/06: Variation of Time in Effect filed April 12/2006: http://www.e-laws.gov.on.ca/DBLaws/Source/Regs/English/2006/R06111_e.htm Quebec News release (French): http://communiques.gouv.qc.ca/gouvqc/communiques/GPQF/Decembre2006/07/c5073… Legal Time Act assented to December 12/2006: http://www2.publicationsduquebec.gouv.qc.ca/dynamicSearch/telecharge.php?ty… New Brunswick News release: http://www.gnb.ca/cnb/news/pre/2005e1737pr.htm Act to Amend the Time Definition Act assented to June 22/2006: http://www.gnb.ca/0062/acts/BBA-2006/Chap-19.pdf Nova Scotia News release: http://www.gov.ns.ca/news/details.asp?id=20060425004 Royal Gazette with regulation 62/2006 on page 244: http://www.gov.ns.ca/just/regulations/rg2/2006/ma1206.pdf Prince Edward Island Act to Amend the Time Uniformity Act assented to May 24/2006: http://www.assembly.pe.ca/bills/pdf_chapter/62/3/chapter-41.pdf Newfoundland and Labrador News release: http://www.releases.gov.nl.ca/releases/2007/mpa/0118n03.htm Act to Amend the Standard Time Act assented to Dec 12/2006: http://www.hoa.gov.nl.ca/hoa/bills/Bill0634.htm Yukon News release: http://www.gov.yk.ca/news/2006/06-164.html O.I.C 2006/127: Daylight Saving Time ordered July 13/2006: http://www.gov.yk.ca/legislation/regs/oic2006_127.pdf Northwest Territories News release (Press "Daylight Savings Time Change" to see pop-up): http://www.exec.gov.nt.ca/currentnews/currentPR.asp?mode=archive It is not clear if legislation has actually been drafted. Nunavut No formal announcement has been made from the Nunavut Government. The premier of Nunavut claimed in August of 2005 that he did not want to touch the issue; nothing more has been heard since. It is likely Nunavut will eventually follow the rest of the country but there will certainly be confusion on March 11/2007 if no formal announcement is made. Currently the TZ database and Microsoft make assumptions that Nunavut will follow the rest of the country. If you find errors in the web page listed at the top of this e-mail or in this e-mail itself, please let me know. I may be somewhat unreachable for the next few days so forgive me I don't immediately respond to e-mail. -chris

3 3

FW: Looking for US timezone data files
by Olson, Arthur David (NIH/NCI) [E] Jan. 31, 2007

Jan. 31, 2007

I'm forwarding this message from Michele Teifke, who is not on the time zone mailing list. Those of you who are on the time zone mailing list should direct replies appropriately. Michele: what you've downloaded is the source code for the time zone compiler and source files; you get to run the source files through the compiler to create the binary files that actually get used by operating systems. Note that the "backward" source file is what's processed to create binary files such as "US/Central". Mailing list folks: this introduces a more general question--is there any open-to-the-public collection of time zone binary files? --ado ________________________________ From: Michele Teifke [mailto:mteifke@myrio.com] Sent: Wednesday, January 31, 2007 1:34 PM To: tz(a)lecserver.nci.nih.gov Subject: Looking for US timezone data files I downloaded the timezone data files from the link you gave on this page. But the set of files is incomplete, it does not contain the US subdirectory of data files. i.e.: US/Pacific, US/Central. Could you tell me if there is a place I can download a complete list of these files. thanks, Michele

1 0

Looking for US timezone data files
by Michele Teifke Jan. 31, 2007

Jan. 31, 2007

I downloaded the timezone data files from the link you gave on this page. But the set of files is incomplete, it does not contain the US subdirectory of data files. i.e.: US/Pacific, US/Central. Could you tell me if there is a place I can download a complete list of these files. thanks, Michele

1 0

2007 DST update included in tzdata-2006m-2.el3 ?
by Ali Darab Jan. 30, 2007

Jan. 30, 2007

Hello, I was wondering if the 2007 DST update for USA is included in tzdata-2006m-2.el3. Thank you, Ali Darab

1 0

DST rules for Istanbul, Turkey
by Nirav Jk Vora Jan. 30, 2007

Jan. 30, 2007

Hi, I am Nirav from the Java Technology Centre, IBM. I am working for the L3 team here. Sometime back, one of my colleagues Amar Devegowda, had mailed regarding updation of the DST rules for Istanbul,Turkey. Actually as per the current rule that is being used in the JVM Daylight saving was supposed to start at 3.00AM . But as per the latest rule from the below link, Daylight timings start from 1.00AM. We were asked to provide an official link where these changes were stated. I hope this link will serve the purpose so that the database can be updated with the latest DST rules for Istanbul. http://wwp.greenwichmeantime.com/time-zone/europe/european-u nion/turkey/ Please do contact me for any further queries that may be there. With Warm Regards ------------------------------------------------------------------ Nirav J Vora Team member, JVM L3 Support(AIX) IBM India Software Lab, Bangalore ( Office: +91-8025094142 È Mobile: +91-9945383481 + e-Mail: nirav.vora(a)in.ibm.com ------------------------------------------------------------------ JVM Diagnostics Reference @ IBM Internal: http://w3.hursley.ibm.com/java/jim/j2se/ibmproduceddocumentation/javadiagno… External: http://www.ibm.com/developerworks/java/jdk/diagnosis/ ------------------------------------------------------------------

1 0

FW:
by Olson, Arthur David (NIH/NCI) [E] Jan. 26, 2007

Jan. 26, 2007

I'm forwarding this message from Vikash, who is not on the time zone mailing list. Those of you who are on the time zone mailing list should direct replies appropriatey. --ado -----Original Message----- From: Jha, Vikash Kumar [mailto:vikash.kumar-jha@hp.com] Sent: Thursday, January 18, 2007 3:59 AM To: tz(a)lecserver.nci.nih.gov Subject: Hi, I am using RedHat linux 2.4.18 ....For updating for new DST rules .. What are the things I should do...? Please let me know. Regars Vikash

2 1

TZ database format specification
by Sean B. Durkin Jan. 25, 2007

Jan. 25, 2007

Hello, Where can I find the specification for the format of the files within the TZ database? I am developing a Delphi (pascal) program to do time zone conversions, using the TZ database. Faithfully, Sean B. Durkin

6 9

Mexico DST news
by Jesper Norgaard Welen Jan. 23, 2007

Jan. 23, 2007

I have not found any single news item that any political decision has been taken whether to follow in Mexico the new US DST rule (that is a month longer than the old one). After the legal fight between former president Vicente Fox and former Mexico City mayor Manuel Lopez Obrador it was clarified in supreme court that DST issues remain with the Congress. On the page of the Energy Saving Trust of Mexico http://www.fide.org.mx/servicios/verano.html it says that DST (spanish: horario de verano) will start in 2007 Sunday 1.st. of April, and end Sunday 28.th. of October (old US-style DST). In the following page http://www.cenam.mx/HoraExacta.asp there is an explanation of that USA will change their schedule to be from Second Sunday of March at 2:00 until First Sunday of November at 2:00 while Mexico will continue with the old DST that is from First Sunday of April at 2:00 to Last Sunday of October at 2:00. However, I'm willing to bet a dinner on that Mexico will follow US from one of these two scenarios: (a) A hasty just-in-time decision puts Mexico on US DST just before 11.th. of March 2007. (b) Next year, a decision is made to put Mexico on the new US style DST, e.g. starting 9.th. of March 2008. Of course at the moment it looks like Mexico is in good company since Cuba, Haiti and Turks & Caicos Islands will also follow old-style US DST. But that is also a reason to keep a close eye on these countries, which might possibly change to keep it simpler to do business with the US (essentially the argument for Canada to change). I found the page http://www.cddhcu.gob.mx/bibliot/publica/inveyana/polisoc/horver/capitulo5.h tm which belongs to the Mexican Congrees (Camara de Diputados) that mentions the different timezone rules in Mexico since 1921. A fair amount of it corresponds well with the tz database (and therefore with Shanks, I presume) but there are differences. If everything is taken literally, there are at least a need to introduce new timezones for the states Campeche, Tamaulipas, Tabasco+CHS, Baja California Sur, Durango, Veracruz+Oaxaca, and Coahuila. Before I go too far with deciphering this, I would like to hear the general opinion about if this is an authoritative source or not - after all the Congress only recently got authority over timezone issues in Mexico (formally), and this list might have some goofed up details from extracting from old documents by "new" people. It does seem odd that there is no activity between 1948 and 1981. But perhaps we should just rely on Shanks for that period. Particularly I would like Paul Eggert's/David Olson's opinion on this. 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 3

Comparing updates
by Dillard, Tom Jan. 22, 2007

Jan. 22, 2007

Hi, I am hoping someone can direct me to what I hope is an easy question. I would like to compare the TZ differences between 2006m down to 2006p. What changes went in between those versions? Thanks, Tom Dillard | 972-461-4116 | tom.dillard(a)tekelec.com

1 0

variations on GMT-8:00
by Curtis Doty Jan. 19, 2007

Jan. 19, 2007

Hi, this is just historical curiosity. I notice that "Rule CA" is applied to Zone America/Los_Angeles (and therefore US/Pacific and US/Pacific-New). But Zone PST8PDT does not have these same (California?) rules. Is there a political precedence for this? I see the bulk of the differences are the period from 1948 until the Uniform Time Act. But it's also curious that America/Los_Angeles references the US rule that defines PST from 1983 to 1918; whereas PST8PDT does not. Why this discrepancy between PST8PDT and the equivalent geographically named zones that use PST? If there is an online explanation for this kind of thing, I'd happily go RTFW. ../C

5 4

(no subject)
by Jha, Vikash Kumar Jan. 18, 2007

Jan. 18, 2007

Hi, I am using RedHat linux 2.4.18 ....For updating for new DST rules .. What are the things I should do...? Please let me know. Regars Vikash

1 0

FW: Cross building tzcode
by Olson, Arthur David (NIH/NCI) [E] Jan. 11, 2007

Jan. 11, 2007

Let's see if we can include the attachment this time, yes? --ado -----Original Message----- From: John Faith [mailto:jfaith@freescale.com] Sent: Thursday, January 11, 2007 1:39 PM To: tz(a)lecserver.nci.nih.gov Subject: Cross building tzcode Hello, In the hope that this might be useful to someone else, attached is a patch to the main tzcode Makefile that we use to cross build. The reason for the patch is that in a cross-compiling environment, generating the data files requires a zic which runs on the host and the target requires the cross-built binary, so the Makefile generates both. I have tested this with ARM targets. We build using a rpm .spec file with something like: make HOST_CC=<path_to_the_host_cc> TOPDIR=%{__prefix} TZDIR=%{_prefix}/share/zoneinfo ETCDIR=%{_prefix}/usr/bin By the way, you can probably ignore the parts about "nawk"->"awk" (I did not have nawk installed), and the bit about "ksh"->"bash" (I didn't have ksh). Thanks! , John Faith Freescale Semiconductor --- timezone-2006n/Makefile.orig 2006-10-02 12:32:16.000000000 -0700 +++ timezone-2006n/Makefile 2006-10-19 10:25:23.000000000 -0700 @@ -218,9 +218,11 @@ CFLAGS= zic= ./zic ZIC= $(zic) $(ZFLAGS) +zic-host= ./zic-host +ZIC-HOST= $(zic-host) $(ZFLAGS) # The name of a Posix-compliant `awk' on your system. -AWK= nawk +AWK= awk # The path where SGML DTDs are kept. SGML_SEARCH_PATH= $(TOPDIR)/share/doc/sgml-lib/REC-html401-19991224/ @@ -244,8 +246,15 @@ VALIDATE_ENV = \ cc= cc CC= $(cc) -DTZDIR=\"$(TZDIR)\" +# Get host compiler for cross environment. If HOST_CC is not defined, +# assume non-cross build. +ifndef HOST_CC + HOST_CC=$(CC) +endif + TZCSRCS= zic.c localtime.c asctime.c scheck.c ialloc.c TZCOBJS= zic.o localtime.o asctime.o scheck.o ialloc.o +TZCOBJS-HOST= zic-host.o localtime-host.o asctime-host.o scheck-host.o ialloc-host.o TZDSRCS= zdump.c localtime.c ialloc.c TZDOBJS= zdump.o localtime.o ialloc.o DATESRCS= date.c localtime.c logwtmp.c strftime.c asctime.c @@ -278,12 +287,12 @@ ENCHILADA= $(DOCS) $(SOURCES) $(DATA) $( SHELL= /bin/sh -all: tzselect zic zdump $(LIBOBJS) +all: tzselect zic zic-host zdump $(LIBOBJS) ALL: all date install: all $(DATA) $(REDO) $(TZLIB) $(MANS) $(TABDATA) - $(ZIC) -y $(YEARISTYPE) \ + $(ZIC-HOST) -y $(YEARISTYPE) \ -d $(TZDIR) -l $(LOCALTIME) -p $(POSIXRULES) -rm -f $(TZDIR)/iso3166.tab $(TZDIR)/zone.tab cp iso3166.tab zone.tab $(TZDIR)/. @@ -314,15 +323,18 @@ zdump: $(TZDOBJS) zic: $(TZCOBJS) yearistype $(CC) $(CFLAGS) $(LFLAGS) $(TZCOBJS) $(LDLIBS) -o $@ +zic-host: $(TZCOBJS-HOST) yearistype + $(HOST_CC) $(CFLAGS) $(LFLAGS) $(TZCOBJS-HOST) $(LDLIBS) -o $@ + yearistype: yearistype.sh cp yearistype.sh yearistype chmod +x yearistype -posix_only: zic $(TDATA) - $(ZIC) -y $(YEARISTYPE) -d $(TZDIR) -L /dev/null $(TDATA) +posix_only: zic-host $(TDATA) + $(ZIC-HOST) -y $(YEARISTYPE) -d $(TZDIR) -L /dev/null $(TDATA) -right_only: zic leapseconds $(TDATA) - $(ZIC) -y $(YEARISTYPE) -d $(TZDIR) -L leapseconds $(TDATA) +right_only: zic-host leapseconds $(TDATA) + $(ZIC-HOST) -y $(YEARISTYPE) -d $(TZDIR) -L leapseconds $(TDATA) # In earlier versions of this makefile, the other two directories were # subdirectories of $(TZDIR). However, this led to configuration errors. @@ -333,9 +345,9 @@ right_only: zic leapseconds $(TDATA) # Therefore, the other two directories are now siblings of $(TZDIR). # You must replace all of $(TZDIR) to switch from not using leap seconds # to using them, or vice versa. -other_two: zic leapseconds $(TDATA) - $(ZIC) -y $(YEARISTYPE) -d $(TZDIR)-posix -L /dev/null $(TDATA) - $(ZIC) -y $(YEARISTYPE) \ +other_two: zic-host leapseconds $(TDATA) + $(ZIC-HOST) -y $(YEARISTYPE) -d $(TZDIR)-posix -L /dev/null $(TDATA) + $(ZIC-HOST) -y $(YEARISTYPE) \ -d $(TZDIR)-leaps -L leapseconds $(TDATA) posix_right: posix_only other_two @@ -364,6 +376,7 @@ tzselect: tzselect.ksh sed \ -e 's|AWK=[^}]*|AWK=$(AWK)|g' \ -e 's|TZDIR=[^}]*|TZDIR=$(TZDIR)|' \ + -e 's|/bin/ksh|/bin/bash|g' \ <$? >$@ chmod +x $@ @@ -423,4 +436,8 @@ scheck.o: private.h strftime.o: tzfile.h zic.o: private.h tzfile.h +# Rules for host objects +%-host.o: %.c + $(HOST_CC) $(CFLAGS) -c $< -o $@ + .KEEP_STATE:

1 0

Cross building tzcode
by John Faith Jan. 11, 2007

Jan. 11, 2007

Hello, In the hope that this might be useful to someone else, attached is a patch to the main tzcode Makefile that we use to cross build. The reason for the patch is that in a cross-compiling environment, generating the data files requires a zic which runs on the host and the target requires the cross-built binary, so the Makefile generates both. I have tested this with ARM targets. We build using a rpm .spec file with something like: make HOST_CC=<path_to_the_host_cc> TOPDIR=%{__prefix} TZDIR=%{_prefix}/share/zoneinfo ETCDIR=%{_prefix}/usr/bin By the way, you can probably ignore the parts about "nawk"->"awk" (I did not have nawk installed), and the bit about "ksh"->"bash" (I didn't have ksh). Thanks! , John Faith Freescale Semiconductor --- timezone-2006n/Makefile.orig 2006-10-02 12:32:16.000000000 -0700 +++ timezone-2006n/Makefile 2006-10-19 10:25:23.000000000 -0700 @@ -218,9 +218,11 @@ CFLAGS= zic= ./zic ZIC= $(zic) $(ZFLAGS) +zic-host= ./zic-host +ZIC-HOST= $(zic-host) $(ZFLAGS) # The name of a Posix-compliant `awk' on your system. -AWK= nawk +AWK= awk # The path where SGML DTDs are kept. SGML_SEARCH_PATH= $(TOPDIR)/share/doc/sgml-lib/REC-html401-19991224/ @@ -244,8 +246,15 @@ VALIDATE_ENV = \ cc= cc CC= $(cc) -DTZDIR=\"$(TZDIR)\" +# Get host compiler for cross environment. If HOST_CC is not defined, +# assume non-cross build. +ifndef HOST_CC + HOST_CC=$(CC) +endif + TZCSRCS= zic.c localtime.c asctime.c scheck.c ialloc.c TZCOBJS= zic.o localtime.o asctime.o scheck.o ialloc.o +TZCOBJS-HOST= zic-host.o localtime-host.o asctime-host.o scheck-host.o ialloc-host.o TZDSRCS= zdump.c localtime.c ialloc.c TZDOBJS= zdump.o localtime.o ialloc.o DATESRCS= date.c localtime.c logwtmp.c strftime.c asctime.c @@ -278,12 +287,12 @@ ENCHILADA= $(DOCS) $(SOURCES) $(DATA) $( SHELL= /bin/sh -all: tzselect zic zdump $(LIBOBJS) +all: tzselect zic zic-host zdump $(LIBOBJS) ALL: all date install: all $(DATA) $(REDO) $(TZLIB) $(MANS) $(TABDATA) - $(ZIC) -y $(YEARISTYPE) \ + $(ZIC-HOST) -y $(YEARISTYPE) \ -d $(TZDIR) -l $(LOCALTIME) -p $(POSIXRULES) -rm -f $(TZDIR)/iso3166.tab $(TZDIR)/zone.tab cp iso3166.tab zone.tab $(TZDIR)/. @@ -314,15 +323,18 @@ zdump: $(TZDOBJS) zic: $(TZCOBJS) yearistype $(CC) $(CFLAGS) $(LFLAGS) $(TZCOBJS) $(LDLIBS) -o $@ +zic-host: $(TZCOBJS-HOST) yearistype + $(HOST_CC) $(CFLAGS) $(LFLAGS) $(TZCOBJS-HOST) $(LDLIBS) -o $@ + yearistype: yearistype.sh cp yearistype.sh yearistype chmod +x yearistype -posix_only: zic $(TDATA) - $(ZIC) -y $(YEARISTYPE) -d $(TZDIR) -L /dev/null $(TDATA) +posix_only: zic-host $(TDATA) + $(ZIC-HOST) -y $(YEARISTYPE) -d $(TZDIR) -L /dev/null $(TDATA) -right_only: zic leapseconds $(TDATA) - $(ZIC) -y $(YEARISTYPE) -d $(TZDIR) -L leapseconds $(TDATA) +right_only: zic-host leapseconds $(TDATA) + $(ZIC-HOST) -y $(YEARISTYPE) -d $(TZDIR) -L leapseconds $(TDATA) # In earlier versions of this makefile, the other two directories were # subdirectories of $(TZDIR). However, this led to configuration errors. @@ -333,9 +345,9 @@ right_only: zic leapseconds $(TDATA) # Therefore, the other two directories are now siblings of $(TZDIR). # You must replace all of $(TZDIR) to switch from not using leap seconds # to using them, or vice versa. -other_two: zic leapseconds $(TDATA) - $(ZIC) -y $(YEARISTYPE) -d $(TZDIR)-posix -L /dev/null $(TDATA) - $(ZIC) -y $(YEARISTYPE) \ +other_two: zic-host leapseconds $(TDATA) + $(ZIC-HOST) -y $(YEARISTYPE) -d $(TZDIR)-posix -L /dev/null $(TDATA) + $(ZIC-HOST) -y $(YEARISTYPE) \ -d $(TZDIR)-leaps -L leapseconds $(TDATA) posix_right: posix_only other_two @@ -364,6 +376,7 @@ tzselect: tzselect.ksh sed \ -e 's|AWK=[^}]*|AWK=$(AWK)|g' \ -e 's|TZDIR=[^}]*|TZDIR=$(TZDIR)|' \ + -e 's|/bin/ksh|/bin/bash|g' \ <$? >$@ chmod +x $@ @@ -423,4 +436,8 @@ scheck.o: private.h strftime.o: tzfile.h zic.o: private.h tzfile.h +# Rules for host objects +%-host.o: %.c + $(HOST_CC) $(CFLAGS) -c $< -o $@ + .KEEP_STATE:

2 1

Canada DST Rules for 2007
by Johan Lindfors Jan. 10, 2007

Jan. 10, 2007

Hi, I'm verifying Canada DST in 2007 Rules and there seems to be conflict with documentation in these pages and in the source page. (Also I may be the conflict ;-)) But please could you verify this: These two pages: http://home.tiscali.nl/~t876506/TZworld.html#nam http://home.tiscali.nl/~t876506/Multizones.html#ca Versus source pages: http://inms-ienm.nrc-cnrc.gc.ca/time_services/daylight_saving_e.html http://inms-ienm.nrc-cnrc.gc.ca/faq_time_e.html#5 Possible conflicts: 1. Can not found explanation from source page why DST should end Last Sun of October in following Cities instead of First Sunday in November(Canada)? Canada >=2007 on Mar Sun>=8 2:00 1:00 Canada >=2007 off Nov Sun>=1 2:00 0 Winn on Apr Sun>=1 2:00 1:00 Winn off Oct lastSun 2:00s 0 Edm on Apr Sun>=1 2:00 1:00 Edm off Oct lastSun 2:00 0 Vanc on Apr Sun>=1 2:00 1:00 Vanc off Oct lastSun 2:00 0 NT_YK on Apr Sun>=1 2:00 1:00 NT_YK off Oct lastSun 2:00 0 2. In the source page there are defined that Manitoba that is same as Winnipeg DST ends 3:00 instead of 2:00. Winn on Apr Sun>=1 2:00 1:00 Winn off Oct lastSun 2:00s 0 Br Johan Lindfors

1 0

Re: FW: suggestion for simplified represention of timezone rules
by Paul Eggert Jan. 9, 2007

Jan. 9, 2007

Robert Hodge <roberth(a)sisconet.com> writes: > It's not a source code issue. I have been able to compile it on windows. > The problem is that the resultant files don't work correctly. They > don't reflect the rules that are defined in the zoneinfo source files. In what sense do the files not work, exactly? For example, does your zic's output match the output generated by zic on GNU/Linux or Unix machines? If so, then the problem is not with the way you built zic; it lies somewhere else. If not, then exactly how does the output differ? > It appears that the existing zoneinfo 'compilers' are misinterpreting > the text data and are building binary zone files incorrectly. zic should be quite reliable on GNU/Linux and Unix platforms, as its output is used in a lot of places. Occasionally we get bug reports, and we do fix any specific bugs that are reported. It is certainly quite possible that there is a portability bug when zic is run on non-POSIXish platforms. However, your report did not contain enough details for us to know what the bug is, or how to reproduce it.

1 0

suggestion for simplified represention of timezone rules
by Robert Hodge Jan. 8, 2007

Jan. 8, 2007

Hello, I have been doing extensive work with the tz database, and while the data is quite useful, it is not in the most accessible format. I have had little success using the zic compiler or any of the source code, and have been forced to do my own parsing and analysis of the data. One aspect of the representation of rules I find awkward is the notation for the day on which a rule takes effect. There are rules such as "lastSun" or "Sun>=8", etc. While descriptive, they are are hard to process. I would like to suggest a better approach. It takes the form "d op nn", where 'd' is the day-of-week, 0=Sun to 6=Sat 'op' is a comparison code of '<', '=' or '>', and 'nn' is a 2-digit day number (may be 00 or 32) The comparision code works as follows: '=' nn is an exact value '<' rule describes the last day less than nn '>' rule describes the first day greater than nn Examples: 0>07 first Sun > 7 (same as first Sun >= 8) 0<32 last Sun < 32 (same as "lastSun") 0=27 Sun the 27th of the month When a range of years are involved in a rule, there is no exact day-of-week, and in such cases, '9' may be used as a place-holder: 9=01 the first day of the month, regardless of what day-of-week it is There is little need to use a day-of-week with >, since the value would always be the same. Example: 9>07 means: first day of the month (regardless of day of week) that is > 7 is always 8. It is conceivable that 9<nn could be used, but the only case where it would have any merit is in February: 9<32 last day of the month For months other than Feb, the value is a constant for a given month, and for Feb it depends on the leap-year status. Since no one (that I know of) does anthing about DST in Feb, we can safely eliminate the 9<nn form as well as the 9>nn form. The conversion from existing rules to this format is pretty straightforward: lastSun 0<32 '32' is constant for 'last' Sun>=8 0>07 subtract 1 from the tz rule value Sun<=21 0<22 add 1 to the tz rule value May 1 9=01 for May 1 of any year May 1 1980 4=01 May 1 1980 is a Thursday Hope you find this interesting. Regards, Robert Hodge

4 3

Tzcode2007a.tar.gz and tzdata2007a.tar.gz
by Olson, Arthur David (NIH/NCI) [E] Jan. 8, 2007

Jan. 8, 2007

The files... ftp://elsie.nci.nih.gov/pub/tzcode2007a.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tzdata2007a.tar.gz ...are now available. These reflect the changes circulated last week on the time zone mailing list by Paul Eggert (as well as Derick Rethan's Asmara change and Oscar van Vlijmen's Easter Island local mean time change). These also reflect the symbolic link changes circulated in December. --ado

1 0

Added info for US 2007 DST change?
by kevin＠ir.iit.edu Jan. 5, 2007

Jan. 5, 2007

Hi, I recently downloaded and compiled the latest zoneinfo db files. After doing a zdump -v on CST6CDT and EST5EDT it appears that they are still showing the old DST changes, however if I check the america file in the source it appears to have the correct info. Could I just be compiling it wrong or am I missing something here. Thank You, Kevin

1 0