- tz - lists.iana.org

Re: tzcode1999e.tar.gz and tzdata1999e.tar.gz
by Ulrich Drepper Aug. 17, 1999

Aug. 17, 1999

Ado, > The files > ftp://elsie.nci.nih.gov/pub/tzcode1999e.tar.gz > and > ftp://elsie.nci.nih.gov/pub/tzdata1999e.tar.gz Unfortunately the files are not readable in the moment: -r-------- 1 8800 0 92586 Aug 17 19:28 tzcode1999e.tar.gz -r-------- 1 8800 0 104493 Aug 17 19:28 tzdata1999e.tar.gz -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------

1 0

tzcode1999e.tar.gz and tzdata1999e.tar.gz
by Olson, Arthur David (NCI) Aug. 17, 1999

Aug. 17, 1999

The files ftp://elsie.nci.nih.gov/pub/tzcode1999e.tar.gz and ftp://elsie.nci.nih.gov/pub/tzdata1999e.tar.gz are now available. These files incorporate the changes circulated last week by Paul Eggert on the time zone mailing list, although the change to handling of DST-specifying time zone names has been commented out for now (search for "XXX" in "localtime.c" for details). These files also do not make any changes to the start of DST in Brazil. In addition to Paul's changes, there are updates to "Arts.htm" and cleanups of URLs. I imagine we'll see 1999f shortly with both changes in "localtime.c" and "southamerica"; folks can judge whether to await 1999f before downloading. --ado

1 0

FW: Changes in Brazil's daylight savings
by Olson, Arthur David (NCI) Aug. 17, 1999

Aug. 17, 1999

Ricardo is not on the time zone list; be sure to include Ricardo in replies if appropriate. --ado -----Original Message----- From: Ricardo Reis [SMTP:rreis@ms.com] Sent: Tuesday, August 17, 1999 12:09 PM To: tz(a)elsie.nci.nih.gov Subject: Changes in Brazil's daylight savings Hi, just to inform that Brazil's daylight savings has been changed. Now it will start on Oct 03 1999 and will end on Feb 27 2000. I am attaching a southamerica file that includes this changes, but I am not experienced in this kind of updates, please rewrite it. Regards, Ricardo R. B. Reis <<southamerica.rreis>>

3 2

Changes in Brazil's daylight savings
by Ricardo Reis Aug. 17, 1999

Aug. 17, 1999

Hi, just to inform that Brazil's daylight savings has been changed. Now it will start on Oct 03 1999 and will end on Feb 27 2000. I am attaching a southamerica file that includes this changes, but I am not experienced in this kind of updates, please rewrite it. Regards, Ricardo R. B. Reis

1 0

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