- 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

Re: Time Zone FTP
by Alex LIVINGSTON July 8, 1999

July 8, 1999

[In error, sent direct to Cliff Hancuff only first.] >It seems in the entanglement of transfering all my files to my new >hot rod of a computer I've misplaced the FTP address for the >world time zone file. > >If it is not too much trouble, could I ask that you save me from >the continued misery of trying to find which bookmark file I put >that in? I'd like to download the latest revisions. > >TIA > >Cliff Hancuff That would be ftp://elsie.nci.nih.gov//pub/ unless I'm mistaken. --Alex

1 0

FW: Time Zones
by Olson, Arthur David (NCI) July 7, 1999

July 7, 1999

-----Original Message----- From: Daniel C. Sobral [SMTP:dcs@newsguy.com] Sent: Wednesday, February 03, 1999 8:18 AM To: tz(a)elsie.nci.nih.gov Subject: Time Zones I'd like to point out that what you call "Zone America/Sao_Paulo", the brazilian "legal time", is actually known as _Brasilia_ time zone in Brazil. -- Daniel C. Sobral (8-DCS) dcs(a)gns.com.br To see you is to sympathize.

4 4

Time Zone FTP
by CHancuff＠aol.com July 7, 1999

July 7, 1999

It seems in the entanglement of transfering all my files to my new hot rod of a computer I've misplaced the FTP address for the world time zone file. If it is not too much trouble, could I ask that you save me from the continued misery of trying to find which bookmark file I put that in? I'd like to download the latest revisions. TIA Cliff Hancuff

1 0

Timezones for US
by Sullivan N. Beck July 6, 1999

July 6, 1999

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/ --------------------

1 0

Re: ISO 14652 draft on POSIX date/time/tz
by Ulrich Drepper July 5, 1999

July 5, 1999

"Joseph S. Myers" <jsm28(a)cam.ac.uk> writes: > The first thing I wonder about this is what implementation experience > there is of including timezone specifications in the locale specification > as this does? After all, when C9X revisions were being discussed it was > insisted that any significant new features should be based on previous > implementation experience! The timezone stuff in 14652 is completly useless. The rules and everything are far more complicated then anything which can be expressed in the LC_TIME specification. I complained about this but since 14652 is now rejected I don't care that much anymore. All I will do (for glibc 2.2) is to allow the specification determine the name of the timezone and then the normal tzdata files are consulted for the real information. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------

1 0

ISO 14652 draft on POSIX date/time/tz
by Markus Kuhn July 5, 1999

July 5, 1999

Those of you interested in upcoming ISO standards related to date/time/ timezone APIs for POSIX systems should have a look at http://www.cl.cam.ac.uk/~mgk25/volatile/ISO-14652.pdf especially section 4.7 (8 pages). This is the usual holy ISO top secret draft stuff for the enlightened inner circles only, so don't tell anyone where you found it. I feel that some of the things it introduces (e.g., the ISO 8601 B.C. notation) might need a bit more scrutinizing and alignment with ISO C9x strftime(), but see for yourself. Editor of this seems to be Keld Simonsen <keld(a)dkuug.dk> and responsible is <http://anubis.dkuug.dk/JTC1/SC22/WG20/> where comments should be directed to have impact. Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>

2 1

Re: TZ not working
by Paul Stewart June 16, 1999

June 16, 1999

The perl-tzlib is not maintained by the folks on this list -- just me. If I had to guess, I'd imagine the problem is that your timezone database is not yet compiled, or isn't in the directory pointed to at "TZDIR" in Makefile.PL. Please follow up your queries directly to me. -- Paul In message <12594.990616(a)cl.spb.ru> you write: >Hello tz, > > I Installed perl-tzlib. > Run the test script tztest.pl, and it says > > 14:11:15 1999 > 14:11:15 1999 > 929527875 > 929527875 > > I suppose it have to give me different times. > > What can be wrong? >Best regards, > Webmaster mailto:webmaster@cl.spb.ru > >

1 0

64-bit time_t and tz file format
by alan perry June 10, 1999

June 10, 1999

A couple of days ago, I posted something to this list about how to go about changing the tz file format to support a 64-bit time_t value. I have heard nothing back. I was looking through the tzcode to see if this problem has been addressed already and found the following comment in the zic source. > ** The tz file format currently allows at most 32-bit quantities. > ** This restriction should be removed before signed 32-bit values > ** wrap around in 2038, but unfortunately this will require a > ** change to the tz file format. So, has anyone been looking into this issue? As I noted earlier, the current tz file format doesn't scale well to a 64-bit time_t and all of the possible additional timezone transitions that result from the addition years that can be represented. As OS vendors (including the one that I used to work for) consider what to do with time_t when their OS adds 64-bit support and how to deal with 2038, they might be tempted to come up with their own solution if it doesn't get addressed by the elsie code. alan

2 1

FW: 64-bit time_t and tz file format
by Olson, Arthur David (NCI) June 10, 1999

June 10, 1999

-----Original Message----- From: alan perry [SMTP:esprit@jps.net] Sent: Thursday, June 10, 1999 1:18 PM To: tz(a)elsie.nci.nih.gov Subject: 64-bit time_t and tz file format A couple of days ago, I posted something to this list about how to go about changing the tz file format to support a 64-bit time_t value. I have heard nothing back. I was looking through the tzcode to see if this problem has been addressed already and found the following comment in the zic source. > ** The tz file format currently allows at most 32-bit quantities. > ** This restriction should be removed before signed 32-bit values > ** wrap around in 2038, but unfortunately this will require a > ** change to the tz file format. So, has anyone been looking into this issue? As I noted earlier, the current tz file format doesn't scale well to a 64-bit time_t and all of the possible additional timezone transitions that result from the addition years that can be represented. As OS vendors (including the one that I used to work for) consider what to do with time_t when their OS adds 64-bit support and how to deal with 2038, they might be tempted to come up with their own solution if it doesn't get addressed by the elsie code. alan

1 0

FW: 64-bit time_t
by Olson, Arthur David (NCI) June 10, 1999

June 10, 1999

-----Original Message----- From: Alan Perry [SMTP:esprit@best.com] Sent: Tuesday, June 08, 1999 6:00 PM To: tz(a)elsie.nci.nih.gov Subject: 64-bit time_t Not sure if this has been discussed before, has anyone been thinking about the effect of a 64-bit time_t on the zoneinfo file? It seems that just substituting a set of 8-byte values for the transition times could result in really big zoneinfo files, particularly when you consider that there are many more possible transition times. alan perry

1 0

GMT Delta Confusion
by Richard L. Shockney June 9, 1999

June 9, 1999

I recently designed a time zone converter and reference site using the excellent database that is maintained at this site. Conversions between time zones appear as expected except when the time zone involves one of the Etc/GMT+ or Etc/GMT- designations. To provide a specific example (and maintain my own sanity) assume the following time zones: GMT, Etc/GMT-5, and US/Central With DST currently in effect, US/Central is 5 hrs behind GMT. Therefore, GMT - US/Central = +5. However, the database indicates that GMT - 'Etc/GMT-5' = -5. Or, stated another way that GMT plus 5 hrs equals Etc/GMT-5 (?) Most people would associate GMT-5 with "the time zone which is 5 hrs behind GMT." However, the database seems to have this defined as "the time zone for which GMT is 5 hrs behind." Can someone confirm that the results I obtained are reproducible? Is there something I do not understand or are the definitions for the Etc/GMT+n and Etc/GMT-n designations reversed in the database? Thanks for your help. Rich Shockney Timezoneconverter.com

2 2

64-bit time_t
by Alan Perry June 8, 1999

June 8, 1999

Not sure if this has been discussed before, has anyone been thinking about the effect of a 64-bit time_t on the zoneinfo file? It seems that just substituting a set of 8-byte values for the transition times could result in really big zoneinfo files, particularly when you consider that there are many more possible transition times. alan perry

1 0

US vs. European Date Notation
by Markus Kuhn June 8, 1999

June 8, 1999

May be someone on this list has some insight about this topic: A journalist of the Wall Street Journal has contacted me as part of his research for a feature article about date notations. He noted that more and more Americans now start to use the European day, month, year notation instead of the traditional month, day, year, and he now realizes that thanks to ISO 8601 all this is moving into the wrong direction anyway. He would be very interested into any pointers of the history of these three date notations, and actually I am quite interested as well. Why do Americans write dates as "December 31, 1999" while Europeans write "31 December 1999", etc.? Why are in East Asia Bigendian dates more common? Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>

6 8

DST in the media
by Olson, Arthur David (NCI) May 20, 1999

May 20, 1999

"Good news." "What did they do? Extend Daylight Saving Time year round?" Professional tanner George Hamilton in dialog from a May, 1999 episode of the syndicated television series "Baywatch" --ado

1 0

Time Zones Information
by ZinaFishberg May 19, 1999

May 19, 1999

Dear Sir/Madam: Information systems department of our company (Seabury&Smith) is involved in building a marketing Data Warehouse. We store information on address and phone for all our customers. Part of this information is the Time Zone. We have to be able to uniquely identify the Time Zone based on the area code or address (state, city, or county ). Also, it's important to be able to identify the correct Time Zone for sates and Area Codes that cross Time Zones (for example, North Dakota). Could you, please, provide help to us regarding this matter. Thank you.

1 0