- tz - lists.iana.org

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

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