- tz - lists.iana.org

RE: tz changes for Australia 2000 Olympics, Jordan, Poland, Brazi l, etc.
by Olson, Arthur David (NCI) Aug. 16, 1999

Aug. 16, 1999

... * Modify localtime.c to default to the current US rules if the TZ string specifies DST without rules, and if we can't load the default rules. ... + if (*name == '\0' && load_result != 0) + /* + ** Default to current US rules if TZ has no rules + ** and we can't load the default rules, + */ + name = ",M4.1.0,M10.5.0"; ... At the least we may want to refer to "US rules as of 1999-08-16" rather than "current US rules." We may also want to cite chapter and verse of an international standard (if applicable) to explain why U.S. rules are being used (to avoid bashing of U.S. computer imperialists). --ado

1 0

DST changes in australasia due to 2000 Olympics
by cfields＠kapaa.eng.sun.com Aug. 11, 1999

Aug. 11, 1999

I am fixing a zoneinfo bug in Solaris. One of our customers has pointed out that daylight saving should be fixed for NSW due to the Sydney Olympics. The NSW government web site, http://dir.gis.nsw.gov.au/cgi-bin/genobject/document/other/daylightsaving/t… shows the following: -------- Daylight saving will commence on the last Sunday in October at 2:00am EST and continue until the last Sunday in March at 3:00am EDST. 1998 - 1999 Start: Sunday October 25, 1998 Finish: Sunday March 28, 1999 1999 - 2000 Start: Sunday October 31, 1999 Finish: Sunday March 26, 2000 2000 - 2001 Start: Sunday August 27, 2000 Finish: Sunday March 25, 2001 (Starting at 2.00am and Finishing at 2.00am) -------- In tzdata1999d (australasia 7.46), Rule AV and AN show the daylight saving change on Aug 26 in 2000. Would the following fix the correct set of timezones that are adopting this change? % diff australasia australasia.fix 116c116 < Rule AV 2000 only - Aug 26 2:00s 1:00 - --- > Rule AV 2000 only - Aug lastSun 2:00s 1:00 - 136c136 < Rule AN 2000 only - Aug 26 2:00s 1:00 - --- > Rule AN 2000 only - Aug lastSun 2:00s 1:00 - Carol Fields carol.fields(a)eng.sun.com

1 0

FW: correction for tzdata/leapseconds
by Olson, Arthur David (NCI) July 22, 1999

July 22, 1999

Please include Michael Deckers in any replies; Michael is not part of the time zone mailing list. --ado -----Original Message----- From: Michael Deckers [SMTP:Michael.Deckers@mch6.siemens.de] Sent: Thursday, July 22, 1999 6:29 AM To: tz(a)elsie.nci.nih.gov Subject: correction for tzdata/leapseconds Just a quibble in the file "@(#)leapseconds 7.11" in ftp://elsie.nci.nih.gov/pub/tzdata1999d.tar.gz: # The International Earth Rotation Service periodically uses leap seconds # to keep UTC to within 0.9 s of TAI (atomic time); see ***************** This becomes correct only with UT1 in place of TAI. For instance: within 0.9 s of UT1 (Universal Time 1, the primary time scale measuring the rotation of the Earth) Since the rates of UTC and TAI are the same, the difference between TAI and UTC increases at each instant a leap second is inserted in UTC; currently it is 32 s. ------------------------------------------------------------------------ Michael H Deckers email: Michael.Deckers(a)mch6.siemens.de ---------------------------- end of mail -------------------------------

2 1

correction for tzdata/leapseconds
by Michael Deckers July 22, 1999

July 22, 1999

Just a quibble in the file "@(#)leapseconds 7.11" in ftp://elsie.nci.nih.gov/pub/tzdata1999d.tar.gz: # The International Earth Rotation Service periodically uses leap seconds # to keep UTC to within 0.9 s of TAI (atomic time); see ***************** This becomes correct only with UT1 in place of TAI. For instance: within 0.9 s of UT1 (Universal Time 1, the primary time scale measuring the rotation of the Earth) Since the rates of UTC and TAI are the same, the difference between TAI and UTC increases at each instant a leap second is inserted in UTC; currently it is 32 s. ------------------------------------------------------------------------ Michael H Deckers email: Michael.Deckers(a)mch6.siemens.de ---------------------------- end of mail -------------------------------

1 0

FW: timezone question
by Olson, Arthur David (NCI) July 19, 1999

July 19, 1999

Be sure direct replies to Durk, who's not on the time zone mailing list. --ado -----Original Message----- From: Durk Talsma [SMTP:d.talsma@direct.a2000.nl] Sent: Friday, July 16, 1999 11:09 AM To: tz(a)elsie.nci.nih.gov Subject: timezone question Hello, First of all, please let me introduce myself, my name is Durk Talsma, and I am currently helping in developing a GPL'ed Open Source Flightsimulator (http://www.flightgear.org) One of the things I'm currently working on is getting the local time right for any given location of an aircraft. Using your tzcode and tzdata packages, I started experimenting, and currently I am able to select the nearest timezone relative to an aircraft's position. I also found out that by faking a TZ environment variable, I'm capable of retrieving the right local time on my linux box. However, one of our goals is portability, and I don't know whether this trick will also work on other platforms, such as Windows or the Mac, using their native localtime() functions. So for this reason, I consider redistributing your timezone definition files with flightgear, along with a modified version of the glibc's localtime() function. For this reason, I have two questions. First, do you think it is necessary to do this, or is there a relatively simple way to get this information from the native OS'ses? And second, are we allowed to use your timezone information files, or code, and redistribute them with our project? By the way, the email adres I'm posting to right now was the only adress I could find for contacting you. Currently, I don't know who I'm sending this to, and I also don't know whether I'm sending this message to a private mail adress or a mailinglist. I also hope that my questions are appropriate to send to this adress. I've attached my latest message to the flightgear developers mailinglist below, to explain a little further what I'm working on. Thanks for reading. Best regards, Durk Talsma Hi, In part, this message is to give a small update on my timezone parsing code, and in part it is also intended to get some advice. First of all, it looks like I made good progress on the timezone parsing code. Currently, I'm able to parse the timezone database, and select the nearest timezone, based on the angle between my current location and the location of the timezone centerpoints, as described in the zone.tab file (thanks Norman!). Currently, I'm only using a spherical world model, but since I've written a little class to store geographical coordinates, this should be pretty easy to convert to something a little more complex. As for retaining the current local time, my original intention was to write some code of my own to parse the timezone values, but just before doing so, I found out that these functions are part of glibc already. So, after hacking around a little, I found out that localtime is determined through an environment var, that points to a file containing timezone info. So under linux, this stuff becomes pretty simple: 1. set up a fake environment var e.g. (pseudo code) char ** fake = { "europe/Amsterdam", 0}; environ = fake; 2. Get the time getlocaltime(); 3. Restore environ = oldEnviron; // point the environment to its origninal location I'm also pretty convinced that this won't work under other platforms, as those have a different mechanism for retrieving timezone info. So my idea would be to adapt the glibc code for use in flightgear, and also making the timezone informationfiles part of the fgfsbase package. After all, this is pretty close to my original idea of writing my own tz parser. This would save me quite some time. On the other hand, and this is my question: if somebody has a better idea, than I'd be very interested. Regards, Durk -- ----------------------------------------------------------------------- You can contact me at: pn_talsma(a)macmail.psy.uva.nl (work) talsma(a)uvapsy.psy.uva.nl (more work) d.talsma(a)direct.a2000.nl (home at last) Or visit my website at: http://people.a2000.nl/dtals ---------------------------------------------------------------------- "Dave, this conversation can serve no further purpose anymore, goodbye" - HAL 9000 - -- Please visit the FGFS web page: http://www.flightgear.org For help on using this list (especially unsubscribing), send a message to "fgfs-devel-request(a)flightgear.org" with a single line of text: "help".

2 1

timezone question
by Durk Talsma July 16, 1999

July 16, 1999

Hello, First of all, please let me introduce myself, my name is Durk Talsma, and I am currently helping in developing a GPL'ed Open Source Flightsimulator (http://www.flightgear.org) One of the things I'm currently working on is getting the local time right for any given location of an aircraft. Using your tzcode and tzdata packages, I started experimenting, and currently I am able to select the nearest timezone relative to an aircraft's position. I also found out that by faking a TZ environment variable, I'm capable of retrieving the right local time on my linux box. However, one of our goals is portability, and I don't know whether this trick will also work on other platforms, such as Windows or the Mac, using their native localtime() functions. So for this reason, I consider redistributing your timezone definition files with flightgear, along with a modified version of the glibc's localtime() function. For this reason, I have two questions. First, do you think it is necessary to do this, or is there a relatively simple way to get this information from the native OS'ses? And second, are we allowed to use your timezone information files, or code, and redistribute them with our project? By the way, the email adres I'm posting to right now was the only adress I could find for contacting you. Currently, I don't know who I'm sending this to, and I also don't know whether I'm sending this message to a private mail adress or a mailinglist. I also hope that my questions are appropriate to send to this adress. I've attached my latest message to the flightgear developers mailinglist below, to explain a little further what I'm working on. Thanks for reading. Best regards, Durk Talsma Hi, In part, this message is to give a small update on my timezone parsing code, and in part it is also intended to get some advice. First of all, it looks like I made good progress on the timezone parsing code. Currently, I'm able to parse the timezone database, and select the nearest timezone, based on the angle between my current location and the location of the timezone centerpoints, as described in the zone.tab file (thanks Norman!). Currently, I'm only using a spherical world model, but since I've written a little class to store geographical coordinates, this should be pretty easy to convert to something a little more complex. As for retaining the current local time, my original intention was to write some code of my own to parse the timezone values, but just before doing so, I found out that these functions are part of glibc already. So, after hacking around a little, I found out that localtime is determined through an environment var, that points to a file containing timezone info. So under linux, this stuff becomes pretty simple: 1. set up a fake environment var e.g. (pseudo code) char ** fake = { "europe/Amsterdam", 0}; environ = fake; 2. Get the time getlocaltime(); 3. Restore environ = oldEnviron; // point the environment to its origninal location I'm also pretty convinced that this won't work under other platforms, as those have a different mechanism for retrieving timezone info. So my idea would be to adapt the glibc code for use in flightgear, and also making the timezone informationfiles part of the fgfsbase package. After all, this is pretty close to my original idea of writing my own tz parser. This would save me quite some time. On the other hand, and this is my question: if somebody has a better idea, than I'd be very interested. Regards, Durk -- ----------------------------------------------------------------------- You can contact me at: pn_talsma(a)macmail.psy.uva.nl (work) talsma(a)uvapsy.psy.uva.nl (more work) d.talsma(a)direct.a2000.nl (home at last) Or visit my website at: http://people.a2000.nl/dtals ---------------------------------------------------------------------- "Dave, this conversation can serve no further purpose anymore, goodbye" - HAL 9000 - -- Please visit the FGFS web page: http://www.flightgear.org For help on using this list (especially unsubscribing), send a message to "fgfs-devel-request(a)flightgear.org" with a single line of text: "help".

1 0

No leap second this December
by Markus Kuhn July 12, 1999

July 12, 1999

1 0

Bulletin C number 18
by IERS/CB July 12, 1999

July 12, 1999

INTERNATIONAL EARTH ROTATION SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE BUREAU CENTRAL DE L'IERS 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 : iers(a)obspm.fr Paris, 12 Juillet 1999 Bulletin C 18 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 December 1999. 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 Central Bureau of IERS

1 0

FW: Timezones for US
by Olson, Arthur David (NCI) July 8, 1999

July 8, 1999

-----Original Message----- From: Sullivan N. Beck [SMTP:sbeck@cise.ufl.edu] Sent: Tuesday, July 06, 1999 3:48 PM To: tz(a)elsie.nci.nih.gov Subject: Timezones for US On Solaris 2.6, I noticed that the output from zdump seemed a bit odd. The first lines are: US/Eastern Sat Dec 14 20:45:52 1901 GMT = Sat Dec 14 16:45:52 1901 EWT isdst=0 US/Eastern Sun Mar 31 06:59:59 1918 GMT = Sun Mar 31 02:59:59 1918 EWT isdst=0 ... I'm sure that 1901 shouldn't be in a wartime timezone. I checked the northamerica file (which, BTW, contains exactly the same rules as are in the 1999d tzdata package). I see the following lines: # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule US 1918 1919 - Mar lastSun 2:00 1:00 W # War Rule US 1918 1919 - Oct lastSun 2:00 0 S Rule US 1942 only - Feb 9 2:00 1:00 W # War Rule US 1945 only - Sep 30 2:00 0 S Rule US 1967 max - Oct lastSun 2:00 0 S Rule US 1967 1973 - Apr lastSun 2:00 1:00 D Rule US 1974 only - Jan 6 2:00 1:00 D Rule US 1975 only - Feb 23 2:00 1:00 D Rule US 1976 1986 - Apr lastSun 2:00 1:00 D Rule US 1987 max - Apr Sun>=1 2:00 1:00 D # US Eastern time, represented by New York # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER Rule NYC 1920 only - Mar lastSun 2:00 1:00 D Rule NYC 1920 only - Oct lastSun 2:00 0 S Rule NYC 1921 1966 - Apr lastSun 2:00 1:00 D Rule NYC 1921 1954 - Sep lastSun 2:00 0 S Rule NYC 1955 1966 - Oct lastSun 2:00 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/New_York -4:56:02 - LMT 1883 Nov 18 12:00 -5:00 US E%sT 1920 -5:00 NYC E%sT 1942 -5:00 US E%sT 1946 -5:00 NYC E%sT 1967 -5:00 US E%sT Unless I'm missing something, this means that from Nov 18, 1883 to Jan 1, 1920, America/New_York is using the rules named "US". The problem is, there are no "US" rule prior to 1918. A quick glance shows the same thing for America/Chicago, America/Denver, and America/ Los_Angelas. Should there be another Zone line defining an alternate rule, or another "US" rule? ---------------------------- Sullivan Beck ----------------------------- sbeck(a)cise.ufl.edu | This space reserved for some saying demonstrating CSE 314E | great wisdom, wit, or insight. I'll fill it in PH : (352) 392-1057 | just as soon as I have any of the above. Fax: (352) 392-1220 | ------------------- http://www.cise.ufl.edu/~sbeck/ --------------------

2 1

RE: Timezones for US
by Olson, Arthur David (NCI) July 8, 1999

July 8, 1999

(Be sure to include Sullivan when replying; Sullivan is not on the time zone mailing list. -----Original Message----- From: Sullivan N. Beck [SMTP:sbeck@cise.ufl.edu] Sent: Tuesday, July 06, 1999 3:48 PM To: tz(a)elsie.nci.nih.gov Subject: Timezones for US On Solaris 2.6, I noticed that the output from zdump seemed a bit odd. The first lines are: US/Eastern Sat Dec 14 20:45:52 1901 GMT = Sat Dec 14 16:45:52 1901 EWT isdst=0 US/Eastern Sun Mar 31 06:59:59 1918 GMT = Sun Mar 31 02:59:59 1918 EWT isdst=0 ... Things seem okay here aboard the mother ship: Script started on Thu Jul 08 09:00:22 1999 flower$ ./zdump -v US/Eastern | head -5 US/Eastern Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 15:45:52 1901 EST isdst=0 US/Eastern Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 15:45:52 1901 EST isdst=0 US/Eastern Sun Mar 31 06:59:59 1918 UTC = Sun Mar 31 01:59:59 1918 EST isdst=0 US/Eastern Sun Mar 31 07:00:00 1918 UTC = Sun Mar 31 03:00:00 1918 EWT isdst=1 US/Eastern Sun Oct 27 05:59:59 1918 UTC = Sun Oct 27 01:59:59 1918 EWT isdst=1 flower$ exit script done on Thu Jul 08 09:00:40 1999 --ado

1 0