- tz - lists.iana.org

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