- tz - lists.iana.org

Timezone histories
by John Brehm Feb. 21, 2004

Feb. 21, 2004

Group: Is there a site or resource that I can quickly go to that contains histories of daylight savings date on and off dates for the last 30 years for North American, European, South Africa, and Pacific Rim countries? Thank you, John Brehm

1 0

Brazil - update
by Rodrigo Severo Feb. 3, 2004

Feb. 3, 2004

Hi, The Brazilian National Observatory has recently updated/corrected some info about the 1994/1995 DST. According to the new info available the state of Mato Grosso also had DST in this period. I'm sending here a small patch to include the info in tzdata. I used tzdata2003e as my reference. TIA, Rodrigo Severo -- ---------------------------------------------------- Rodrigo Severo Fábrica de Idéias Fone: +55(61)321 1357 Fax: +55(61)223 1712 SBS - Quadra 2 - Ed. Empire Center - Sala 1301 Brasília/DF - Brasil CEP: 70.070-904 ---------------------------------------------------- diff -cr tzdata2003e/southamerica tzdata2003e.new/southamerica *** tzdata2003e/southamerica 2003-12-15 12:31:42.000000000 -0200 --- tzdata2003e.new/southamerica 2004-02-02 14:51:01.000000000 -0200 *************** *** 536,543 **** # # 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 # --- 536,541 ----

2 2

FW: Brazil DST data for 2004
by Olson, Arthur David (NIH/NCI) Feb. 2, 2004

Feb. 2, 2004

Otavio Exel is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Otavio Exel [mailto:oexel@economatica.com.br] Sent: Friday, January 30, 2004 1:42 PM To: tz(a)lecserver.nci.nih.gov Subject: Brazil DST data for 2004 Dear TZ, According to http://pcdsh01.on.br/HvInic03.htm DST here in Brazil ends on 2004-02-15 00:00:00 []s, -- Otavio Exel /<\oo/>\ oexel(a)economatica.com.br

2 1

Brazil DST data for 2004
by Otavio Exel Jan. 30, 2004

Jan. 30, 2004

Dear TZ, According to http://pcdsh01.on.br/HvInic03.htm DST here in Brazil ends on 2004-02-15 00:00:00 []s, -- Otavio Exel /<\oo/>\ oexel(a)economatica.com.br

1 0

FW: Time Zone: Malaysia & Singapore
by Olson, Arthur David (NIH/NCI) Jan. 28, 2004

Jan. 28, 2004

Mok Ly Yng is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Mok Ly Yng [mailto:lymok@starhub.net.sg] Sent: Friday, January 23, 2004 9:01 AM To: tz(a)lecserver.nci.nih.gov Subject: Time Zone: Malaysia & Singapore Hi there, I am Mok Ly Yng. I found my name mentioned in the latest version of the tz data file. I have added a few other points to the Malaysia and Singapore time zone info. These are marked in blue. For both Malaysia and Singapore, for many years in the past versions of this file, the first date was listed as 'Until 1880'. This was the date which prompted my research into the history of legal time in Singapore and Malaysia. It turned out that '1880' was the founding year of Kuala Lumpur. So, it could not have been an 'Until' date. Kuala Lumpur kept its own Local Mean Time of 6:46:46 until it was changed to Singapore's Mean Time on 01 Jan 1901, along with the rest of the other Malay States under British rule. The difference of 2 sec between 6:46:46 and 6:46:48 (as in the original version) was probably due to the rounding off of arc seconds in the longitude value. Singapore was founded in 1819 and had kept different local mean times depending on the different longitude values as determined by different authorities over the years. The only uncertainty remaining is the WWII years of 1942-1945. I am still trying to find out the exact dates of time changes. Regards, Mok ========== # @(#)asia 7.73 # Malaysia # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule NBorneo 1935 1941 - Sep 14 0:00 0:20 TS # one-Third Summer 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 <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. [This did not happen. K.L. had its own L.M.T. of 6:46:46 from GMT.] # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Kuala_Lumpur 6:46:46 - LMT 1901 Jan 1 # K.L. Local Mean Time 6:55:25 - SMT 1905 Jun 1 # Singapore M.T. 7:00 - MALT 1933 Jan 1 # Malaya Time 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 7:30 - MALT 1982 Jan 1 8:00 - MYT # Malaysia Time # Singapore # The data here are taken from Mok Ly Yng (2003-10-30) # <http://www.math.nus.edu.sg/aslaksen/teaching/timezone.html <http://www.math.nus.edu.sg/aslaksen/teaching/timezone.html> >. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Singapore 6:55:25 - LMT 1901 Jan 1 # Local Mean Time 6:55:25 - SMT 1905 Jun 1 # Singapore M.T. 7:00 - MALT 1933 Jan 1 # Malaya Time 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 7:30 - MALT 1965 Aug 9 # independence 7:30 - SGT 1982 Jan 1 # Singapore Time 8:00 - SGT

2 1

DST history
by Helder & Julie Jan. 23, 2004

Jan. 23, 2004

Could you please let me know when Britain, Canada, and Portugal first began using daylight savings time. I have been looking for that information but seem unable to find it. Thank you.

1 0

Time Zone: Malaysia & Singapore
by Mok Ly Yng Jan. 23, 2004

Jan. 23, 2004

Hi there, I am Mok Ly Yng. I found my name mentioned in the latest version of the tz data file. I have added a few other points to the Malaysia and Singapore time zone info. These are marked in blue. For both Malaysia and Singapore, for many years in the past versions of this file, the first date was listed as 'Until 1880'. This was the date which prompted my research into the history of legal time in Singapore and Malaysia. It turned out that '1880' was the founding year of Kuala Lumpur. So, it could not have been an 'Until' date. Kuala Lumpur kept its own Local Mean Time of 6:46:46 until it was changed to Singapore's Mean Time on 01 Jan 1901, along with the rest of the other Malay States under British rule. The difference of 2 sec between 6:46:46 and 6:46:48 (as in the original version) was probably due to the rounding off of arc seconds in the longitude value. Singapore was founded in 1819 and had kept different local mean times depending on the different longitude values as determined by different authorities over the years. The only uncertainty remaining is the WWII years of 1942-1945. I am still trying to find out the exact dates of time changes. Regards, Mok ========== # @(#)asia 7.73 # Malaysia # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule NBorneo 1935 1941 - Sep 14 0:00 0:20 TS # one-Third Summer 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. [This did not happen. K.L. had its own L.M.T. of 6:46:46 from GMT.] # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Kuala_Lumpur 6:46:46 - LMT 1901 Jan 1 # K.L. Local Mean Time 6:55:25 - SMT 1905 Jun 1 # Singapore M.T. 7:00 - MALT 1933 Jan 1 # Malaya Time 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 7:30 - MALT 1982 Jan 1 8:00 - MYT # Malaysia Time # Singapore # 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 1901 Jan 1 # Local Mean Time 6:55:25 - SMT 1905 Jun 1 # Singapore M.T. 7:00 - MALT 1933 Jan 1 # Malaya Time 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 7:30 - MALT 1965 Aug 9 # independence 7:30 - SGT 1982 Jan 1 # Singapore Time 8:00 - SGT

1 0

Time Links
by Murray Triplett Jan. 19, 2004

Jan. 19, 2004

Dear Sir or Madam, My name is Murray Triplett, and I am the webmaster of Instatime.com, an informational site established to educate web users of global time zones. With an easy-to-read world map, all time zones are shown in real time on one page, which is perfect for a quick resource or presentation graphic. I would like to link to do a link exchange with your site (http://www.twinsun.com/tz/tz-link.htm) to improve the users' web experience from both of our ends. Please let me know if this is possible, and if you'd like to move forward. Thank you, Murray Triplett Webmaster, InstaTime __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

1 0

Time and time zones on Mars (draft text)
by Paul Eggert Jan. 19, 2004

Jan. 19, 2004

Wednesday's L.A. Times article by Jia-Rui Chong about JPL workers' wristwatches keeping Martian time prompted me to do a little bit of research about time zones on Mars. I'll eventually propose a patch to the "Theory" file, but thought I'd first submit the following rough draft on this mailing list for comment. ----- 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 Rovers mission 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-01-12). Jia-Rui Chong, "Workdays Fit for a Martian", Los Angeles Times <http://www.latimes.com/la-sci-marstime14jan14,1,3346745.story> (2004-01-14), pp A1, A20-A21.

1 0

IERS Bulletin C 27
by Olson, Arthur David (NIH/NCI) Jan. 15, 2004

Jan. 15, 2004

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, 15 January 2004 Bulletin C 27 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 2004. The difference between UTC and the International Atomic Time TAI is : from 1999 January 1, 0h UTC, until further notice : UTC-TAI = -32 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

Bulletin C number 27
by iers＠hpopa.obspm.fr Jan. 15, 2004

Jan. 15, 2004

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, 15 January 2004 Bulletin C 27 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 2004. The difference between UTC and the International Atomic Time TAI is : from 1999 January 1, 0h UTC, until further notice : UTC-TAI = -32 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

FW: NebulaSearch.com Encyclopedia article about "Time zone"
by Olson, Arthur David (NIH/NCI) Jan. 12, 2004

Jan. 12, 2004

Bryan Johnston is not on the time zone mailing list; direct replies appropriately. -ado -----Original Message----- From: Bryan Johnston [mailto:nebulasearch@yahoo.com] Sent: Sunday, January 11, 2004 3:57 AM To: tz(a)lecserver.nci.nih.gov Subject: NebulaSearch.com Encyclopedia article about "Time zone" The editors at NebulaSearch.com have added a reference link to your page http://www.twinsun.com/tz/tz-link.htm in our encyclopedia article "Time zone" which can be found at http://www.nebulasearch.com/encyclopedia/article/Time_zone.html. We'd be happy if you'd like to link back, but understand if you'd prefer not to. Best, Bryan Johnston Editor, NebulaSearch.com

1 0

NebulaSearch.com Encyclopedia article about "Time zone"
by Bryan Johnston Jan. 11, 2004

Jan. 11, 2004

The editors at NebulaSearch.com have added a reference link to your page http://www.twinsun.com/tz/tz-link.htm in our encyclopedia article "Time zone" which can be found at http://www.nebulasearch.com/encyclopedia/article/Time_zone.html. We'd be happy if you'd like to link back, but understand if you'd prefer not to. Best, Bryan Johnston Editor, NebulaSearch.com

1 0

24:00; Canada
by Olson, Arthur David (NIH/NCI) Dec. 26, 2003

Dec. 26, 2003

Regarding use of "24:00" in data files (which pre-1998 versions of zic can't handle), Martin Smoot wrote: > I would think at some point that we would have to give up on maintaining compatibility with these older versions of zic. after all it has been several years. how many people do not have a compiler to rebuild zic? Visiting this whole 24:00 business didn't happen because of Kiefer Sutherland/Jack Bauer; we did get a report of difficulty from a user trying to pump updated data files through a vendor-supplied zic. If use of 24:00 was in support of some active time zone, we'd have no choice but to abandon efforts at compatibility, but when the use of 24:00 is only to support a limited number of historic transitions in a limited number of places, there's more motive to avoid use of 24:00 (and thus to avoid problems for folks trying to use the data with existing compilers). We do, of course, want to keep the code in place so that people for whom it would be useful can benefit from it. We face more latency in our work with the time zone stuff than do vendors such as Sun with other software. Sun has to implement and distribute changes and give customers time to adopt them before abandoning support. We have to implement and distribute changes, wait for vendors to implement and distribute them, and then wait for customers to adopt them. So our "give up on maintaining compatibility" time frame is, of necessity, longer than folks might be accustomed to. A complicating factor is that the time zone data files do now get processed by alternate readers that aren't part of the time zone package. At this point we've got the "this is a simpler way to do it" comments in the relevant place in the data file. The next step will be to uncomment that stuff and comment out the more complicated (but more generally useable) stuff. I don't know what the best time frame is for doing that; I imagine it's best to do it before the retirement of yours truly (now 8-1/2 years off). ---------------------------------------------- Another piece of fallout from the 24:00 work was the discovery that back during the Great Depression Toronto was making switches at 2:00 a.m. on the first Sunday after the last Saturday in April and September--even if this meant that the switch got pushed back to May or October. Now as currently set up, when zic is asked to make a switch on a day of the month such as... Sun>=25 ...it checks to ensure that there is indeed such a Sunday in the month and fails if there isn't one. I believe it's reasonable to lift this restriction; doing so allows simpler expression of rules covering situations such as those in Toronto, as witness the (regression-tested) changes attached below. As always, the point of the exercise is not so much to deal with what happened in Toronto way back when, but to be prepared to deal with the situation if some wild-eyed legislators decide to adopt such a scheme in the future. --ado ------- zic.c ------- *** /tmp/geta11385 Mon Dec 22 12:35:17 2003 --- /tmp/getb11385 Mon Dec 22 12:35:18 2003 *************** *** 2138,2144 **** wday = LDAYSPERWEEK - 1; --i; } ! if (i < 0 || i >= len_months[isleap(y)][m]) { error(_("no day in month matches rule")); (void) exit(EXIT_FAILURE); } --- 2138,2144 ---- wday = LDAYSPERWEEK - 1; --i; } ! if (i < 0) { error(_("no day in month matches rule")); (void) exit(EXIT_FAILURE); } ------- northamerica ------- *** /tmp/geta11403 Mon Dec 22 12:35:18 2003 --- /tmp/getb11403 Mon Dec 22 12:35:18 2003 *************** *** 989,1000 **** # 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 ! 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 ! Rule Toronto 1933 1940 - Apr lastSun 2:00 1:00 D ! Rule Toronto 1933 only - Oct 1 2:00 0 S ! Rule Toronto 1934 1939 - Sep lastSun 2:00 0 S Rule Toronto 1945 1946 - Sep lastSun 2:00 0 S Rule Toronto 1946 only - Apr lastSun 2:00 1:00 D Rule Toronto 1947 1949 - Apr lastSun 0:00 1:00 D --- 989,998 ---- # 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 ! 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 1939 - Sep lastSun 2:00 0 S ! Rule Toronto 1938 1940 - Apr lastSun 2:00 1:00 D Rule Toronto 1945 1946 - Sep lastSun 2:00 0 S Rule Toronto 1946 only - Apr lastSun 2:00 1:00 D Rule Toronto 1947 1949 - Apr lastSun 0:00 1:00 D

2 1

Use of FILENAME_MAX
by Klaus Klein Dec. 20, 2003

Dec. 20, 2003

While investigating a recent NetBSD bug report (related but turned out to be not an issue), I noticed a use of FILENAME_MAX in tzload() which seems a little wrong. With FILENAME_MAX being sufficient to hold the longest valid pathname, including terminating NUL, it is not necessary to allocate an additional character for the separating slash between `p' and `name'; if that character was consumed by the concatenation, the resulting string would no longer be a valid pathname due to its excessive length. I've also taken the liberty to rearrange the component addition below which seems to have had part in causing our original submitter's misunderstanding, but that's merely cosmetics. Just nitpicking, - Klaus *** localtime.c 15 Dec 2003 15:13:53 -0000 1.1.1.9 --- localtime.c 20 Dec 2003 20:09:07 -0000 *************** *** 284,302 **** ** "FILENAME_MAX expands to an integral constant expression ** that is the size needed for an array of char large enough ** to hold the longest file name string that the implementation ** guarantees can be opened." */ ! char fullname[FILENAME_MAX + 1]; if (name[0] == ':') ++name; doaccess = name[0] == '/'; if (!doaccess) { if ((p = TZDIR) == NULL) return -1; ! if ((strlen(p) + strlen(name) + 1) >= sizeof fullname) return -1; (void) strcpy(fullname, p); (void) strcat(fullname, "/"); (void) strcat(fullname, name); /* --- 284,302 ---- ** "FILENAME_MAX expands to an integral constant expression ** that is the size needed for an array of char large enough ** to hold the longest file name string that the implementation ** guarantees can be opened." */ ! char fullname[FILENAME_MAX]; if (name[0] == ':') ++name; doaccess = name[0] == '/'; if (!doaccess) { if ((p = TZDIR) == NULL) return -1; ! if ((strlen(p) + 1 + strlen(name)) >= sizeof fullname) return -1; (void) strcpy(fullname, p); (void) strcat(fullname, "/"); (void) strcat(fullname, name); /*

1 0

www.bsdi.com/date is dead; is there a good replacement?
by Paul Eggert Dec. 16, 2003

Dec. 16, 2003

For many years "Sources for Time Zone and Daylight Saving Time Data" <http://www.twinsun.com/tz/tz-link.htm> has referred to "Date and Time Gateway" <http://www.bsdi.com/date/> as a simple text-based point-and-click web interface based on the tz data. However, www.bsdi.com has been refusing connections recently. Apparently Wind River (which acquired BSDI a couple of years ago) has decided to shut down BSD/OS. Too bad. I have located <http://www.earth.com/date/> as another web site that serves the same data, but if BSD/OS is being discontinued then I worry that this is only a stopgap. Can anyone suggest a replacement URL? We currently refer to the following URLs but I'm looking for something that is less fancy and that is oriented towards the tz data. http://www.hilink.com.au/times/ http://www.convertit.com/Go/ConvertIt/World_Time/Current_Time.ASP http://timezoneconverter.com/ http://www.holidayfestival.com/ http://www.timeanddate.com/worldclock/

1 0

Tzcode2003e.tar.gz and tzdata2003e.tar.gz
by Olson, Arthur David (NIH/NCI) Dec. 15, 2003

Dec. 15, 2003

The files... ftp://elsie.nci.nih.gov/pub/tzcode2003e.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tzdata2003e.tar.gz ...are now available. These include the changes I recently circulated on the time zone mailing list (primarily code changes) as well as the changes circulated by Paul Eggert (primarily data changes). There are also minor changes to "Makefile" and "northamerica" (in the latter case, Optimization of the "Toronto" rules). More on "24:00" and Toronto to follow. --ado

1 0

light relief from Australia
by Peter Ilieve Dec. 12, 2003

Dec. 12, 2003

The following appears in this week's New Scientist (13 Dec) Feedback and is available on-line at <http://www.newscientist.com/opinion/opfeedback.jsp>: AFTER 30 years of "daylight saving" - moving the clocks forward in the spring and then back again in the autumn - there is still an Abolish Daylight Saving Committee in New South Wales, Australia. Added to the usual claims of such campaigns - for example, that the extra hour of daylight in the evening in summer fades the curtains - is a new one from ADSC spokeswoman Judith Hall, of Gunnedah, who told the Sydney Morning Herald: "No man has the right to choose the time of the rising and setting of the sun, only God." Reader John McCallum, who told us about this, is surprised Hall doesn't explain why God doesn't simply exercise this choice. When people insist on moving their clocks forward, He should just move the sunrise forward and thwart them that way. Never mind 24:00, I wonder how zic would cope with that. :-) This particular ADSC doesn't seem to have a web presence. Searching for `abolish daylight saving' in the archive box at <http://www.smh.com.au> turns up some stuff but they want money for their archive stories. I found one article for free at <http://www.smh.com.au/articles/2003/10/26/1067103271149.html> but I couldn't find the Jeff Corbett column from 29 Oct mentioned in the archive hit summaries. Peter Ilieve peter(a)aldie.co.uk

1 0

Proposed changes to tz package
by Olson, Arthur David (NIH/NCI) Dec. 10, 2003

Dec. 10, 2003

Here are proposed change to the time zone package. Included: * corrections of the spelling of UNIX and of its trademark holder. * correct version number in iso3166.tab * normalize format of comments in localtime.c * change mktime to search temporally backward through used time corrections when making DST adjustments * change Makefile to generate text versions of man pages and to check for uses of 24:00 in input files * change northamerica to avoid use of 24:00 and to normalize a date appearing in a comment * add workman.sh script for generating text versions of man pages * change zic.c to warn about use of 24:00 if the -v option is used * change zic.8 to document warnings about 24:00 --ado ------- europe ------- *** /tmp/geta11168 Thu Dec 4 12:00:25 2003 --- /tmp/getb11168 Thu Dec 4 12:00:25 2003 *************** *** 1,4 **** ! # @(#)europe 7.84 # This data is by no means authoritative; if you think you know better, # go ahead and edit the file (and please send any changes to --- 1,4 ---- ! # @(#)europe 7.85 # This data is by no means authoritative; if you think you know better, # go ahead and edit the file (and please send any changes to *************** *** 1831,1837 **** # # From Andrey A. Chernov <ache(a)nagual.ru> (1996-10-04): # `MSK' and `MSD' were born and used initially on Moscow computers with ! # Unix-like OSes by several developer groups (e.g. Demos group, Kiae group).... # The next step was the UUCP network, the Relcom predecessor # (used mainly for mail), and MSK/MSD was actively used there. # --- 1831,1837 ---- # # From Andrey A. Chernov <ache(a)nagual.ru> (1996-10-04): # `MSK' and `MSD' were born and used initially on Moscow computers with ! # UNIX-like OSes by several developer groups (e.g. Demos group, Kiae group).... # The next step was the UUCP network, the Relcom predecessor # (used mainly for mail), and MSK/MSD was actively used there. # ------- iso3166.tab ------- *** /tmp/geta11187 Thu Dec 4 12:00:25 2003 --- /tmp/getb11187 Thu Dec 4 12:00:25 2003 *************** *** 1,6 **** # ISO 3166 alpha-2 country codes # ! # @(#)iso3166.tab 1.9 # # From Paul Eggert <eggert(a)twinsun.com> (2003-02-04): # --- 1,6 ---- # ISO 3166 alpha-2 country codes # ! # @(#)iso3166.tab 1.14 # # From Paul Eggert <eggert(a)twinsun.com> (2003-02-04): # ------- localtime.c ------- *** /tmp/geta11206 Thu Dec 4 12:00:25 2003 --- /tmp/getb11206 Thu Dec 4 12:00:25 2003 *************** *** 5,11 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.76"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 5,11 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.78"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 1053,1060 **** } /* ! * Re-entrant version of localtime ! */ struct tm * localtime_r(timep, tm) const time_t * const timep; --- 1053,1061 ---- } /* ! ** Re-entrant version of localtime. ! */ ! struct tm * localtime_r(timep, tm) const time_t * const timep; *************** *** 1113,1120 **** } /* ! * Re-entrant version of gmtime ! */ struct tm * gmtime_r(timep, tm) const time_t * const timep; --- 1114,1122 ---- } /* ! * Re-entrant version of gmtime. ! */ ! struct tm * gmtime_r(timep, tm) const time_t * const timep; *************** *** 1503,1508 **** --- 1505,1515 ---- register time_t t; register const struct state * sp; register int samei, otheri; + register int sameind, otherind; + register int i; + register int nseen; + int seen[TZ_MAX_TYPES]; + int types[TZ_MAX_TYPES]; int okay; if (tmp->tm_isdst > 1) *************** *** 1536,1545 **** if (sp == NULL) return WRONG; #endif /* defined ALL_STATE */ ! for (samei = sp->typecnt - 1; samei >= 0; --samei) { if (sp->ttis[samei].tt_isdst != tmp->tm_isdst) continue; ! for (otheri = sp->typecnt - 1; otheri >= 0; --otheri) { if (sp->ttis[otheri].tt_isdst == tmp->tm_isdst) continue; tmp->tm_sec += sp->ttis[otheri].tt_gmtoff - --- 1543,1562 ---- if (sp == NULL) return WRONG; #endif /* defined ALL_STATE */ ! for (i = 0; i < sp->typecnt; ++i) ! seen[i] = FALSE; ! nseen = 0; ! for (i = sp->timecnt - 1; i >= 0; --i) ! if (!seen[sp->types[i]]) { ! seen[sp->types[i]] = TRUE; ! types[nseen++] = sp->types[i]; ! } ! for (sameind = 0; sameind < nseen; ++sameind) { ! samei = types[sameind]; if (sp->ttis[samei].tt_isdst != tmp->tm_isdst) continue; ! for (otherind = 0; otherind < nseen; ++otherind) { ! otheri = types[otherind]; if (sp->ttis[otheri].tt_isdst == tmp->tm_isdst) continue; tmp->tm_sec += sp->ttis[otheri].tt_gmtoff - ------- Makefile ------- *** /tmp/geta11225 Thu Dec 4 12:00:26 2003 --- /tmp/getb11225 Thu Dec 4 12:00:26 2003 *************** *** 1,4 **** ! # @(#)Makefile 7.83 # Change the line below for your time zone (after finding the zone you want in # the time zone files, or adding it to a time zone file). --- 1,4 ---- ! # @(#)Makefile 7.89 # Change the line below for your time zone (after finding the zone you want in # the time zone files, or adding it to a time zone file). *************** *** 268,274 **** WEB_PAGES= tz-art.htm tz-link.htm MISC= usno1988 usno1989 usno1989a usno1995 usno1997 usno1998 \ $(WEB_PAGES) checktab.awk ! ENCHILADA= $(DOCS) $(SOURCES) $(DATA) $(MISC) # And for the benefit of csh users on systems that assume the user # shell should be used to handle commands in Makefiles. . . --- 268,274 ---- WEB_PAGES= tz-art.htm tz-link.htm MISC= usno1988 usno1989 usno1989a usno1995 usno1997 usno1998 \ $(WEB_PAGES) checktab.awk ! ENCHILADA= $(DOCS) $(SOURCES) $(DATA) $(MISC) workman.sh # And for the benefit of csh users on systems that assume the user # shell should be used to handle commands in Makefiles. . . *************** *** 383,392 **** public: $(ENCHILADA) zic -mkdir /tmp/,tzpublic ! for i in $(TDATA) ; do zic -d /tmp/,tzpublic $$i ; done rm -f -r /tmp/,tzpublic $(AWK) -f checktab.awk $(PRIMARY_YDATA) ! tar cf - $(DOCS) $(SOURCES) $(MISC) | gzip -9 > tzcode.tar.gz tar cf - $(DATA) | gzip -9 > tzdata.tar.gz zonenames: $(TDATA) --- 383,394 ---- public: $(ENCHILADA) zic -mkdir /tmp/,tzpublic ! -for i in $(TDATA) ; do zic -v -d /tmp/,tzpublic $$i 2>&1 | grep -v "starting year" ; done ! for i in $(TDATA) ; do zic -d /tmp/,tzpublic $$i; done rm -f -r /tmp/,tzpublic + for i in *.[1-8] ; do sh workman.sh $$i > $$i.txt; done $(AWK) -f checktab.awk $(PRIMARY_YDATA) ! tar cf - $(DOCS) $(SOURCES) $(MISC) *.[1-8].txt | gzip -9 > tzcode.tar.gz tar cf - $(DATA) | gzip -9 > tzdata.tar.gz zonenames: $(TDATA) ------- northamerica ------- *** /tmp/geta11244 Thu Dec 4 12:00:26 2003 --- /tmp/getb11244 Thu Dec 4 12:00:26 2003 *************** *** 1,4 **** ! # @(#)northamerica 7.63 # also includes Central America and the Caribbean # This data is by no means authoritative; if you think you know better, --- 1,4 ---- ! # @(#)northamerica 7.65 # also includes Central America and the Caribbean # This data is by no means authoritative; if you think you know better, *************** *** 405,411 **** -7:00 - MST # From Arthur David Olson (1988-02-13): # A writer from the Inter Tribal Council of Arizona, Inc., ! # notes in private correspondence dated 12/28/87 that "Presently, only the # Navajo Nation participates in the Daylight Saving Time policy, due to its # large size and location in three states." (The "only" means that other # tribal nations don't use DST.) --- 405,411 ---- -7:00 - MST # From Arthur David Olson (1988-02-13): # A writer from the Inter Tribal Council of Arizona, Inc., ! # notes in private correspondence dated 1987-12-28 that "Presently, only the # Navajo Nation participates in the Daylight Saving Time policy, due to its # large size and location in three states." (The "only" means that other # tribal nations don't use DST.) *************** *** 951,958 **** Rule Mont 1924 only - May 17 2:00 1:00 D Rule Mont 1924 1926 - Sep lastSun 2:30 0 S Rule Mont 1925 1926 - May Sun>=1 2:00 1:00 D ! Rule Mont 1927 1937 - Apr lastSat 24:00 1:00 D ! Rule Mont 1927 1937 - Sep lastSat 24:00 0 S Rule Mont 1938 1940 - Apr lastSun 0:00 1:00 D Rule Mont 1938 1939 - Sep lastSun 0:00 0 S Rule Mont 1946 1973 - Apr lastSun 2:00 1:00 D --- 951,968 ---- Rule Mont 1924 only - May 17 2:00 1:00 D Rule Mont 1924 1926 - Sep lastSun 2:30 0 S Rule Mont 1925 1926 - May Sun>=1 2:00 1:00 D ! # The 1927-to-1937 rules can be expressed more simply as ! # Rule Mont 1927 1937 - Apr lastSat 24:00 1:00 D ! # Rule Mont 1927 1937 - Sep lastSat 24:00 0 S ! # The rules below avoid use of 24:00 ! # (which pre-1998 versions of zic cannot handle). ! Rule Mont 1927 only - May 1 0:00 1:00 D ! Rule Mont 1928 1931 - Apr lastSun 0:00 1:00 D ! Rule Mont 1932 only - May 1 0:00 1:00 D ! Rule Mont 1933 1937 - Apr lastSun 0:00 1:00 D ! Rule Mont 1927 1932 - Sep lastSun 0:00 0 S ! Rule Mont 1933 only - Oct 1 0:00 0 S ! Rule Mont 1934 1937 - Sep lastSun 0:00 0 S Rule Mont 1938 1940 - Apr lastSun 0:00 1:00 D Rule Mont 1938 1939 - Sep lastSun 0:00 0 S Rule Mont 1946 1973 - Apr lastSun 2:00 1:00 D *************** *** 975,982 **** Rule Toronto 1928 only - Apr lastSun 2:00 1:00 D Rule Toronto 1929 only - Apr lastSun 0:00 1:00 D Rule Toronto 1929 only - Sep lastSun 0:00 0 S ! Rule Toronto 1930 1937 - Apr lastSat 24:00 1:00 D ! Rule Toronto 1930 1937 - Sep lastSat 24:00 0 S Rule Toronto 1938 1940 - Apr lastSun 0:00 1:00 D Rule Toronto 1938 1939 - Sep lastSun 0:00 0 S Rule Toronto 1945 1946 - Sep lastSun 2:00 0 S --- 985,1001 ---- Rule Toronto 1928 only - Apr lastSun 2:00 1:00 D Rule Toronto 1929 only - Apr lastSun 0:00 1:00 D Rule Toronto 1929 only - Sep lastSun 0:00 0 S ! # The 1930-to-1937 rules can be expressed more simply as ! # Rule Toronto 1930 1937 - Apr lastSat 24:00 1:00 D ! # Rule Toronto 1930 1937 - Sep lastSat 24:00 0 S ! # The rules below avoid use of 24:00 ! # (which pre-1998 versions of zic cannot handle). ! Rule Toronto 1930 1931 - Apr lastSun 0:00 1:00 D ! Rule Toronto 1932 only - May 1 0:00 1:00 D ! Rule Toronto 1933 1937 - Apr lastSun 0:00 1:00 D ! Rule Toronto 1930 1932 - Sep lastSun 0:00 0 S ! Rule Toronto 1933 only - Oct 1 0:00 0 S ! Rule Toronto 1934 1937 - Sep lastSun 0:00 0 S Rule Toronto 1938 1940 - Apr lastSun 0:00 1:00 D Rule Toronto 1938 1939 - Sep lastSun 0:00 0 S Rule Toronto 1945 1946 - Sep lastSun 2:00 0 S ------- private.h ------- *** /tmp/geta11263 Thu Dec 4 12:00:26 2003 --- /tmp/getb11263 Thu Dec 4 12:00:26 2003 *************** *** 21,27 **** #ifndef lint #ifndef NOID ! static char privatehid[] = "@(#)private.h 7.52"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 21,27 ---- #ifndef lint #ifndef NOID ! static char privatehid[] = "@(#)private.h 7.53"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 288,294 **** #endif /* HAVE_INCOMPATIBLE_CTIME_R */ /* ! ** UNIX was a registered trademark of UNIX System Laboratories in 1993. */ #endif /* !defined PRIVATE_H */ --- 288,294 ---- #endif /* HAVE_INCOMPATIBLE_CTIME_R */ /* ! ** UNIX was a registered trademark of The Open Group in 2003. */ #endif /* !defined PRIVATE_H */ ------- Theory ------- *** /tmp/geta11282 Thu Dec 4 12:00:26 2003 --- /tmp/getb11282 Thu Dec 4 12:00:27 2003 *************** *** 1,4 **** ! @(#)Theory 7.13 ----- Outline ----- --- 1,4 ---- ! @(#)Theory 7.14 ----- Outline ----- *************** *** 12,18 **** ----- Time and date functions ----- These time and date functions are upwards compatible with POSIX.1, ! an international standard for Unix-like systems. As of this writing, the current edition of POSIX.1 is: Information technology --Portable Operating System Interface (POSIX (R)) --- 12,18 ---- ----- Time and date functions ----- These time and date functions are upwards compatible with POSIX.1, ! an international standard for UNIX-like systems. As of this writing, the current edition of POSIX.1 is: Information technology --Portable Operating System Interface (POSIX (R)) *************** *** 144,150 **** since the format of zic's input changed slightly in late 1994, and many vendors still do not support the new input format. ! * The Unix Version 7 "timezone" function is not present in this package; it's impossible to reliably map timezone's arguments (a "minutes west of GMT" value and a "daylight saving time in effect" flag) to a time zone abbreviation, and we refuse to guess. --- 144,150 ---- since the format of zic's input changed slightly in late 1994, and many vendors still do not support the new input format. ! * The UNIX Version 7 "timezone" function is not present in this package; it's impossible to reliably map timezone's arguments (a "minutes west of GMT" value and a "daylight saving time in effect" flag) to a time zone abbreviation, and we refuse to guess. ------- workman.sh ------- *** /tmp/geta11301 Thu Dec 4 12:00:27 2003 --- /tmp/getb11301 Thu Dec 4 12:00:27 2003 *************** *** 0 **** --- 1,29 ---- + #! /bin/sh + + # @(#)workman.sh 1.7 + + # Tell groff not to emit SGR escape sequences (ANSI color escapes). + GROFF_NO_SGR=1 + export GROFF_NO_SGR + + echo ".am TH + .hy 0 + .na + .. + .rm }H + .rm }F" | nroff -man - ${1+"$@"} | perl -ne ' + chomp; + s/.\010//g; + s/\s*$//; + if (/^$/) { + $sawblank = 1; + next; + } else { + if ($sawblank && $didprint) { + print "\n"; + $sawblank = 0; + } + print "$_\n"; + $didprint = 1; + } + ' ------- zic.c ------- *** /tmp/geta11320 Thu Dec 4 12:00:27 2003 --- /tmp/getb11320 Thu Dec 4 12:00:27 2003 *************** *** 1,4 **** ! static char elsieid[] = "@(#)zic.c 7.113"; #include "private.h" #include "locale.h" --- 1,4 ---- ! static char elsieid[] = "@(#)zic.c 7.115"; #include "private.h" #include "locale.h" *************** *** 931,936 **** --- 931,938 ---- error(errstring); return 0; } + if (noise && hh == HOURSPERDAY) + warning(_("24:00 not handled by pre-1998 versions of zic")); return eitol(sign) * (eitol(hh * MINSPERHOUR + mm) * eitol(SECSPERMIN) + eitol(ss)); *************** *** 2230,2234 **** } /* ! ** UNIX was a registered trademark of UNIX System Laboratories in 1993. */ --- 2232,2236 ---- } /* ! ** UNIX was a registered trademark of The Open Group in 2003. */ ------- zic.8 ------- *** /tmp/geta11429 Thu Dec 4 12:11:14 2003 --- /tmp/getb11429 Thu Dec 4 12:11:14 2003 *************** *** 81,86 **** --- 81,89 ---- of years representable by .IR time (2) values. + Also complain if a time of 24:00 + (which cannot be handled by pre-1998 versions of zic) + appears in the input. .TP .B \-s Limit time values stored in output files to values that are the same *************** *** 417,420 **** /usr/local/etc/zoneinfo standard directory used for created files .SH "SEE ALSO" newctime(3), tzfile(5), zdump(8) ! .\" @(#)zic.8 7.20 --- 420,423 ---- /usr/local/etc/zoneinfo standard directory used for created files .SH "SEE ALSO" newctime(3), tzfile(5), zdump(8) ! .\" @(#)zic.8 7.21

5 4

RE: compile errors on timezone database
by Olson, Arthur David (NIH/NCI) Dec. 9, 2003

Dec. 9, 2003

Another possibility is to change from... lastSat 24:00 ...to... lastSat 23:59:59 (meaning that changes will be one second premature and that some binary output files will change, but avoiding the dread 60th second.) --ado -----Original Message----- From: Dave Rolsky [mailto:autarch@urth.org] Sent: Wednesday, December 03, 2003 12:41 PM To: Olson, Arthur David (NIH/NCI) Cc: 'Diane Kledzik'; Tz (tz(a)elsie.nci.nih.gov) Subject: RE: compile errors on timezone database On Wed, 3 Dec 2003, Olson, Arthur David (NIH/NCI) wrote: > Another possibility is to change the spelling of... > 24:00 > ...to... > 23:59:60 > ...which works with any version of zic issued 1988 or later. Let's > hear it for leap seconds! Please don't do this. This is a bogus time, because there is no leap second at that time. 24:00 makes a lot more sense. Plus my parsing code already handles it and I don't want to have to make more changes ;) -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/

3 2

RE: America/Chicago zone vs mktime w/tm_isdst!=-1
by Olson, Arthur David (NIH/NCI) Dec. 6, 2003

Dec. 6, 2003

The strange Chicago behavior occurs because for a few months back in 1936 Chicago switched to using Eastern Standard Time; mktime ended up using this information when trying to do a DST correction. The change below should "fix" things; it convinces mktime to work temporally backward through time adjustments that have been used in an area when trying to do a DST correction. (Of course if you really did start out with a 1936 time this is the wrong thing to do, but that's fairly unlikely.) --ado ------- localtime.c ------- *** /tmp/geta23340 Fri Nov 28 12:10:57 2003 --- /tmp/getb23340 Fri Nov 28 12:10:57 2003 *************** *** 5,11 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.76"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 5,11 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.77"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 1503,1508 **** --- 1503,1513 ---- register time_t t; register const struct state * sp; register int samei, otheri; + register int sameind, otherind; + register int i; + register int nseen; + int seen[TZ_MAX_TYPES]; + int types[TZ_MAX_TYPES]; int okay; if (tmp->tm_isdst > 1) *************** *** 1536,1545 **** if (sp == NULL) return WRONG; #endif /* defined ALL_STATE */ ! for (samei = sp->typecnt - 1; samei >= 0; --samei) { if (sp->ttis[samei].tt_isdst != tmp->tm_isdst) continue; ! for (otheri = sp->typecnt - 1; otheri >= 0; --otheri) { if (sp->ttis[otheri].tt_isdst == tmp->tm_isdst) continue; tmp->tm_sec += sp->ttis[otheri].tt_gmtoff - --- 1541,1560 ---- if (sp == NULL) return WRONG; #endif /* defined ALL_STATE */ ! for (i = 0; i < sp->typecnt; ++i) ! seen[i] = FALSE; ! nseen = 0; ! for (i = sp->timecnt - 1; i >= 0; --i) ! if (!seen[sp->types[i]]) { ! seen[sp->types[i]] = TRUE; ! types[nseen++] = sp->types[i]; ! } ! for (sameind = 0; sameind < nseen; ++sameind) { ! samei = types[sameind]; if (sp->ttis[samei].tt_isdst != tmp->tm_isdst) continue; ! for (otherind = 0; otherind < nseen; ++otherind) { ! otheri = types[otherind]; if (sp->ttis[otheri].tt_isdst == tmp->tm_isdst) continue; tmp->tm_sec += sp->ttis[otheri].tt_gmtoff - -----Original Message----- From: tz-request(a)lecserver.nci.nih.gov [mailto:tz-request@lecserver.nci.nih.gov] On Behalf Of Olson, Arthur David (NIH/NCI) Sent: Tuesday, November 25, 2003 7:40 AM To: Tz (tz(a)elsie.nci.nih.gov) Subject: FW: America/Chicago zone vs mktime w/tm_isdst!=-1 Dan Nelson is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Dan Nelson [mailto:dnelson@allantgroup.com] Sent: Monday, November 24, 2003 6:23 PM To: tz(a)lecserver.nci.nih.gov Subject: America/Chicago zone vs mktime w/tm_isdst!=-1 Here's an interesting problem. Usually when mktime() is called with tm_isdst set to 0 or 1, it will interpret the original time as being either in standard or daylight time according to tm_isdst, and update the resulting time_t value (and the struct tm) if the DST flag was wrong. This doesn't seem to happen with the America/Chicago zone. I've attached a simple program that passes three struct tm's to mktime, with three values of tm_isdst each. For most zones, the first and last times change depending on what value of tm_isdst is passed in. For America/Chicago, it looks like tm_isdst is ignored. Is it used correctly for the middle time (since it's in the fall-back range). Someone filed a FreeBSD PR against this back in June ( http://www.freebsd.org/cgi/query-pr.cgi?pr=53899 ), and I've verified the behaviour back to FreeBSD 4.0 (which had imported tzcode1999a). The classictzcode.tar.gz on elsie.nci.nih.gov looks at tm_isdst in all cases, so the change happened sometime between 1994 and 1999. I don't know if there are archives of tzcode sources, or I could pinpoint the exact release. It's not strictly a bug since POSIX basically says that any tm_isdst != -1 results in implementation-defined behaviour, but it's troublesome if the behaviour changes from zone to zone, and the current releases of Solaris, Tru64, AIX, and glibc(Linux) are consistent across timezones (they all adjust the incoming struct tm based on tm_isdst). And, a couple of POSIX/C99 links for the archives: http://www.opengroup.org/onlinepubs/007904975/functions/mktime.html http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/dr_280.htm -- Dan Nelson dnelson(a)allantgroup.com

3 2

FW: America/Chicago zone vs mktime w/tm_isdst!=-1
by Olson, Arthur David (NIH/NCI) Dec. 6, 2003

Dec. 6, 2003

Dan Nelson is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Dan Nelson [mailto:dnelson@allantgroup.com] Sent: Monday, November 24, 2003 6:23 PM To: tz(a)lecserver.nci.nih.gov Subject: America/Chicago zone vs mktime w/tm_isdst!=-1 Here's an interesting problem. Usually when mktime() is called with tm_isdst set to 0 or 1, it will interpret the original time as being either in standard or daylight time according to tm_isdst, and update the resulting time_t value (and the struct tm) if the DST flag was wrong. This doesn't seem to happen with the America/Chicago zone. I've attached a simple program that passes three struct tm's to mktime, with three values of tm_isdst each. For most zones, the first and last times change depending on what value of tm_isdst is passed in. For America/Chicago, it looks like tm_isdst is ignored. Is it used correctly for the middle time (since it's in the fall-back range). Someone filed a FreeBSD PR against this back in June ( http://www.freebsd.org/cgi/query-pr.cgi?pr=53899 ), and I've verified the behaviour back to FreeBSD 4.0 (which had imported tzcode1999a). The classictzcode.tar.gz on elsie.nci.nih.gov looks at tm_isdst in all cases, so the change happened sometime between 1994 and 1999. I don't know if there are archives of tzcode sources, or I could pinpoint the exact release. It's not strictly a bug since POSIX basically says that any tm_isdst != -1 results in implementation-defined behaviour, but it's troublesome if the behaviour changes from zone to zone, and the current releases of Solaris, Tru64, AIX, and glibc(Linux) are consistent across timezones (they all adjust the incoming struct tm based on tm_isdst). And, a couple of POSIX/C99 links for the archives: http://www.opengroup.org/onlinepubs/007904975/functions/mktime.html http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/dr_280.htm -- Dan Nelson dnelson(a)allantgroup.com

2 1

tzcode port to delphi
by Wayne Stanton Dec. 4, 2003

Dec. 4, 2003

Hi there, Does any know of a port of the tzcode to delphi or another windows specific compiler? thanks Wayne Stanton

1 0

FW: tzcode port to delphi
by Olson, Arthur David (NIH/NCI) Dec. 4, 2003

Dec. 4, 2003

Wayne Stanton is on the time zone mailing list, but at a different address than the one from which the message below originated. --ado -----Original Message----- From: Wayne Stanton [mailto:stantonw@optusnet.com.au] Sent: Wednesday, December 03, 2003 3:11 PM To: 'Tz (tz(a)elsie.nci.nih.gov)' Subject: tzcode port to delphi Hi there, Does any know of a port of the tzcode to delphi or another windows specific compiler? thanks Wayne Stanton

1 0

FW: Addition to http://www.twinsun.com/tz/tz-link.htm
by Olson, Arthur David (NIH/NCI) Dec. 4, 2003

Dec. 4, 2003

Steven R. Loomis has been added to the time zone mailing list after this message was received. --ado -----Original Message----- From: Steven R. Loomis [mailto:srl@jtcsv.com] Sent: Wednesday, December 03, 2003 8:32 PM To: tz(a)lecserver.nci.nih.gov Subject: Addition to http://www.twinsun.com/tz/tz-link.htm The International Components for Unicode library for C/C++ (ICU) uses tzdata in its historic time zone calculations. Our URL is http://oss.software.ibm.com/icu/ Would you consider adding a link to the page http://www.twinsun.com/tz/tz-link.htm ? Thank you and regards, Steven R. Loomis

1 0