May 1999 - tz - lists.iana.org

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

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

FW: Tonga planning DST in year 2000
by Olson, Arthur David (NCI) May 13, 1999

May 13, 1999

Note that Eric Ulevik is not on the time zone mailing list -----Original Message----- From: Eric Ulevik Sent: Monday, May 03, 1999 7:23 AM To: tz(a)elsie.nci.nih.gov Subject: Tonga planning DST in year 2000 Tonga gets serious on millennium bid Monday 3 May, 1999 (1:57pm AEST) Kingdom of Tonga is so determined to be the first country in the world to see 2000 that it might introduce daylight saving this year for the first time ever. Tonga prides itself on being the first country in the world to see the sun each day, although New Zealand catches up with Tonga's time zone each summer. Tonga has great plans to welcome in the year 2000 but its hoped for tourist boom has lost some of its shine because New Zealand is claiming that its Chatham Islands will be the first place in the world to greet the New Year. Tonga's director of tourism, who is also secretary of the National Millenium Committee, has a plan to get Tonga back in front. He has proposed a one-off move to tropical daylight saving for Tonga from October to March, which has won approval in principle from the Tongan Government.

1 0

RE: mktime bug?
by Olson, Arthur David (NCI) May 13, 1999

May 13, 1999

I'm unable to duplicate the problem. --ado Script started on Thu May 13 03:49:04 1999 gertrude$ cat mktimetest.c #include <stdio.h> #include <time.h> #include <errno.h> int main() { struct tm tm; time_t secs; memset(&tm, 0, sizeof tm); tm.tm_year = 99; tm.tm_mon = 4; tm.tm_mday = 13; secs = mktime(&tm); printf("secs: %ld\n", secs); if (secs < 0) printf("strerror(errno): %s\n", strerror(errno)); return 0; } gertrude$ cc mktimetest.c libtz.a -o mktimetest gertrude$ TZ=Europe/Paris ./mktimetest secs: 926550000 gertrude$ TZ=America/New_York ./mktimetest secs: 926571600 gertrude$ TZ=CET-1CEST-2 ./mktimetest secs: 926550000 gertrude$ exit script done on Thu May 13 03:50:23 1999

1 0

FW: mktime bug?
by Olson, Arthur David (NCI) May 13, 1999

May 13, 1999

Be sure to direct replies to Guido, who's not on the time zone mailing list. --ado -----Original Message----- From: Guido Flohr [SMTP:gufl0000@stud.uni-sb.de] Sent: Wednesday, May 12, 1999 8:43 PM To: tz(a)elsie.nci.nih.gov Subject: mktime bug? Hi, sorry, it's me again. I have problems with this little piece of code: bash$ cat >mktimetest <<EOF #include <stdio.h> #include <time.h> int main () { struct tm tm; time_t secs; memset (&tm, 0, sizeof tm); tm.year = 99; tm.mon = 4; tm.mday = 13; secs = mktime (&tm); printf ("secs: %ld (%s)\n", secs, strerror (errno)); return 0; } EOF # make mktimetest # TZ=CET-1CEST-2 ./mktimetest secs: -1 (OK) On installations where summertime applies during May mktime returns an error here (happens somewhere in the function time2). If I set tm.tm_isdst = -1; before calling mktime() the function returns the correct time. I have fixed that by inserting the line tmp->tm_isdst = -1; in mktime() before time1() gets called but I'm not sure if this is the right place to do that (or if this is correct at all). Can you verify that behavior or have I messed up my sources? If it is a bug, how should it be fixed? Thanks Guido -- http://stud.uni-sb.de/~gufl0000 mailto:gufl0000@stud.uni-sb.de

1 0

FW: POSIX-TZ without rules
by Olson, Arthur David (NCI) May 13, 1999

May 13, 1999

Be sure to direct replies to Guido, who's not on the time zone mailing list. --ado -----Original Message----- From: Guido Flohr [SMTP:gufl0000@stud.uni-sb.de] Sent: Monday, April 26, 1999 9:46 PM To: arthur_david_olson(a)nih.gov Subject: POSIX-TZ without rules Hello! I'm the current maintainer of the MiNTLib. The MiNTLib is the standard libc for MiNT and MiNT is a free Unix-clone for Atari computers. I've implemented parts of the tzcode and tzdata packages (version 1998c) in the MiNTLib. This went mostly without problems. Two problems arised: First, for testing purposes I set the envariable TZ to "CET-1CEST-2", i. e. a valid POSIX-style string but without explicit rules. I also uninstalled the database for that test. Under these circumstances tzparse() in localtime.c will return an error because it fails to open a default rules file. From what I remember I would say that POSIX demands that the US rules should be applied instead. Anyway, "CET-1CEST-2" is perfectly POSIX-compliant and the library should not return an error then. The GNU libc handles this case by assuming an implicit rule of "M4.1.0,M10.5.0" (commented as "US Federal Law"). My solution is somewhat different: I generated a header "new_york.h" with the disassembled contents of /usr/share/zoneinfo/posix/America/New_York. Now, not giving rules with no time zone database installed has the same effect as linking posixrules to America/New_York (as recommended in the Makefile of tzcode). The second problem: In zic.c, the analysis of the return value of system("yearistype ...") assumes a certain structure of that return value. I think it would be more portable to use the macros from sys/wait.h instead (although this would probably require an additional -D option to cc that determines whether to use POSIX- or BSD-style macros). May sound pedantic, but here's the story: I have happened to introduce a bug in the waitpid() function of the MiNTLib; the upper two bytes of the status pointer weren't zeroed out but contained some garbage. This affected system() because it calls waitpid. The error message from zic was: wild result 27525120 ... australasia line 75, command was "./yearistype 1990 even" Well, I could figure out what happened, but an average user would have had problems, because typing the command literally into the shell simply returned 0. If I understand the sources correctly, the more common error that the yearistype command is not found (e. g. running "zic -y yearistype ..." without "." in $PATH) would also produce quite confusing error messages (but at least the shell would also complain because you don't redirect stderr to /dev/null). Another argument: The specification for system() explicitely demands to use the wait macros to analyse the return value. These macros would have worked in the above described case. From this point of view the garbage in the upper 2 bytes is not even a bug. Apart from that: Thanks for all the work you must have invested into the time zone database! Everything works perfectly fine here. Ciao Guido -- http://stud.uni-sb.de/~gufl0000 mailto:gufl0000@stud.uni-sb.de

4 4

Re: FW: UK Timezone info
by peter＠aldie.co.uk May 12, 1999

May 12, 1999

Robert Brady wrote: > You'll like this : the power to set time-zone in the UK might be devolved > to the Scottish Parliamant and Welsh Assembly. > > See : > > http://www.parliament.the-stationery-office.co.uk/pa/ld199899/ldbills/047/1… > 7.htm A check in the Lords Hansard for 13 April confirms my guess that this is a bit of grandstanding by Lord (Jeffrey) Archer as part of his campaign to become the Mayor of London. See: http://www.parliament.the-stationery-office.co.uk/pa/ld199697/ldhansrd/\ pdvn/lds99/text/90413-03.htm#90413-03_head2 (Note for non UK folk: this is nothing to do with the Lord Mayor of London. The Lord Mayor is mayor of the City of London, the famous `square mile' financial bit of London. The Labour government elected in May 1997 had as one of its policies that London as a whole should have an elected mayor. This is a long delayed response to a previous Conservative government having abolished the Greater London Council. The GLC (as it was always known) was controlled by Labour and was led by Ken Livingstone. Neither main party has yet chosen their candidate for Mayor of London but they both find themselves in a mess because the front runners are Ken Livingstone (the very same) and Lord Archer. Both parties seem to be doing everything possible to avoid actually selecting them as candidates. Oh, the Lord Mayor is also elected after a fashion, by all liverymen of at least one year's standing plus some other City officers, from among the Aldermen who have served as sheriff and have not already been elected Mayor. Is that all clear now? :-) As it was only last year that the Government reserved matters relating to time to Westminster in the Scotland Act (the Welsh Assembly is incapable of legislation) I think the chances of this Bill passing are close to zero. I suggest an alternative: the area inside the M25 motorway should have its own timezone and the rest of us can continue as we are. :-) Peter Ilieve peter(a)aldie.co.uk

1 0

FW: UK Timezone info
by Olson, Arthur David (NCI) May 12, 1999

May 12, 1999

Note that Robert Brady is not on the time zone mailing list. --ado -----Original Message----- From: Robert Brady [SMTP:rwb197@ecs.soton.ac.uk] Sent: Wednesday, May 12, 1999 12:11 PM To: tz(a)elsie.nci.nih.gov Subject: UK Timezone info You'll like this : the power to set time-zone in the UK might be devolved to the Scottish Parliamant and Welsh Assembly. See : http://www.parliament.the-stationery-office.co.uk/pa/ld199899/ldbills/047/1… 7.htm -- Robert.

1 0

UK Timezone info
by Robert Brady May 12, 1999

May 12, 1999

You'll like this : the power to set time-zone in the UK might be devolved to the Scottish Parliamant and Welsh Assembly. See : http://www.parliament.the-stationery-office.co.uk/pa/ld199899/ldbills/047/1… -- Robert.

1 0

FW: FW: Australian Timezone issues.
by Olson, Arthur David (NCI) May 11, 1999

May 11, 1999

-----Original Message----- From: Chris Bitmead [SMTP:chris.bitmead@bigfoot.com] Sent: Tuesday, May 11, 1999 4:30 AM To: 'tz' Cc: Robert Elz Subject: Re: FW: Australian Timezone issues. Robert Elz wrote: > | Has any thought been given to having the Australian EST timezone renamed > | to AEST? > > No. Or at least, I certainly hope it has not. why? > | For example, when a database dumps a time 'Sun May 9 11:07:06 > | EST 1999 in Australia, and then the database reads the time back in, it > | assumes that EST is New York time and everything gets screwed up. > > Any code that does that is simply broken. Time zone names > are a hint to humans. They simply aren't unambiguous. The > two Aust zone abbreviations that are the same as their US > equivalents (EST and CST) aren't the only ambiguous ones > around (and then there are all the places that have no real > concept of a timezone name at all - and the tz database > just invents one for them - most of the countries in South > East Asia are given "ICT", which seems to be "Indo China > Time" which, as a label, means nothing locally > at all). Well I'll report that to the database developers. If that is the official way it is, and it's not just Australia in this boat, then I guess things have to change in how people write code. This is a quote from the POSTGRESQL database documentation... "If the compiler option USE_AUSTRALIAN_RULES is set then EST refers to Australia Eastern Std Time, which has an offset of +10:00 hours from UTC. Australian time zones and their naming variants account for fully one quarter of all time zones in the Postgres time zone lookup table." > | reports when TZ=EST. > > You give ambiguous input, you can expect to get ambiguous ouput. > If you want to specify Australian time, use > TZ=Australia/Sydney or whatever, and for North American, > use TZ=America/New_York. But there doesn't seem to be a portable way to find out the string "Australia/Sydney" on your computer. Everything would be fine and dandy if strftime() returned the zone as "Australia/Sydney", but that's not what it does, it returns the mnumonic EST buried inside the zone file. If the mnumonic was "Australia/Sydney" then fine, but it's not. > You need to > be more precise than just "eastern" anyway to represent > historical times accurately. Well, current times would be a start. > Alternatively, convince the whole world that time zone > names ought always have a country, or region prefix - > perhaps we could have "American Eastern Standard Time" (not > US, as it applies in Canada, and perhaps parts of > Mexico and other parts of Central America as well) and > Australian Eastern Standard Time, and both could be AEST Do we have to convince the world, or merely UNIX operating system vendors? After all, as you say zone names are ambiguous now, so nobody can be relying on them for other than (potentially inaccurate) information. So making them unique could only improve things no? > Time zone names are just an inherantly local phenomenon - > anything, anywhere, which intends to write, and then parse, > a date string needs to be sure that the string contains the > numeric zone offset. Even humans which don't carry time offsets and summer time rules around in their heads?

1 0

FW: Australian Timezone issues.
by Olson, Arthur David (NCI) May 11, 1999

May 11, 1999

Note that Chris is not on the time zone mailing list; be sure that any replies are directed to Chris. --ado -----Original Message----- From: Chris Bitmead [SMTP:chris.bitmead@bigfoot.com] Sent: Sunday, May 09, 1999 11:12 AM To: tz(a)elsie.nci.nih.gov Subject: Australian Timezone issues. I understand this is the appropriate email address for addressing issues with the standard UNIX timezone files. Has any thought been given to having the Australian EST timezone renamed to AEST? The conflicting name with the American EST has caused too much grief for too long. AEST is the proper abbreviation anyway in an international context and is reported on international radio broadcasts that refer to Australian timezones. The current practice of using plain EST simply breaks everything. For example, when a database dumps a time 'Sun May 9 11:07:06 EST 1999 in Australia, and then the database reads the time back in, it assumes that EST is New York time and everything gets screwed up. Another example, typing date in Australia's EST zone gives Sun May 9 11:07:06 EST 1999 But typing TZ=EST date Sat May 8 20:07:06 EST 1999 Inconsistent or what? As far as I know it is only Australian zones which suffer from this stupidity. It basicly renders timezones partly useless in Australia, because the timezone abbreviation of EST is ambiguous, and whenever interpreted, it's always done wrongly as NY time. This means that a lot of UNIX software simply doesn't work properly in Australia. Frankly I count the standard UNIX date program amoungst the many because the time it reports as EST is different to the date it reports when TZ=EST. What would have to be done to get this changed in the zoneinfo files? -- Chris Bitmead http://www.bigfoot.com/~chris.bitmead mailto:chris.bitmead@bigfoot.com

4 8

When Citizens Disagree on Even the Time of Day
by Paul Eggert May 10, 1999

May 10, 1999

On today's op-ed page of the LA Times, Jorge G. Castan~eda, a political scientest and writer in Mexico City, used time zones as a metaphor for the political fragmentation and social dissolution of today's Mexico. Among other things, he writes: One example involves the time zones in the country and the absurd debate that took place in March as to who would adopt daylight saving time. Some states have adopted the hour change, others have not. Some are on U.S. Central time, some on Mountain time and some on Pacific time, while the one that used to go by Eastern time--Quintana Roo, where Cancun is located--decided to go back to Central time. While Mexico City Mayor Cuauhtemoc Cardenas wisely desisted from heeding his rank and file and accepted the federal government's decision to move clocks forward on April 1, it was touch and go for several days. The country cannot even agree, literally, on the time of day. I assume that the ``April 1'' here was the date of Cardenas's decision, not the date the clocks actually moved (which was presumably April 4 as usual in North America these days). We know about Quintana Roo and have some idea of states that fall into all the categories mentioned above, but it perhaps some states have changed since last year, and it would be useful to know exactly what happened in Mexico this spring. Reference: http://www.latimes.com/HOME/NEWS/COMMENT/t000041976.1.html

2 1

Australian Timezone issues.
by Chris Bitmead May 9, 1999

May 9, 1999

I understand this is the appropriate email address for addressing issues with the standard UNIX timezone files. Has any thought been given to having the Australian EST timezone renamed to AEST? The conflicting name with the American EST has caused too much grief for too long. AEST is the proper abbreviation anyway in an international context and is reported on international radio broadcasts that refer to Australian timezones. The current practice of using plain EST simply breaks everything. For example, when a database dumps a time 'Sun May 9 11:07:06 EST 1999 in Australia, and then the database reads the time back in, it assumes that EST is New York time and everything gets screwed up. Another example, typing date in Australia's EST zone gives Sun May 9 11:07:06 EST 1999 But typing TZ=EST date Sat May 8 20:07:06 EST 1999 Inconsistent or what? As far as I know it is only Australian zones which suffer from this stupidity. It basicly renders timezones partly useless in Australia, because the timezone abbreviation of EST is ambiguous, and whenever interpreted, it's always done wrongly as NY time. This means that a lot of UNIX software simply doesn't work properly in Australia. Frankly I count the standard UNIX date program amoungst the many because the time it reports as EST is different to the date it reports when TZ=EST. What would have to be done to get this changed in the zoneinfo files? -- Chris Bitmead http://www.bigfoot.com/~chris.bitmead mailto:chris.bitmead@bigfoot.com

1 0

Re: FW: POSIX-TZ without rules
by Guido Flohr May 5, 1999

May 5, 1999

On Thu, Apr 29, 1999 at 04:39:29PM -0700, Paul Eggert wrote: > From: Guido Flohr [SMTP:gufl0000@stud.uni-sb.de] > Sent: Monday, April 26, 1999 9:46 PM > > for testing purposes I set the envariable TZ to "CET-1CEST-2", > i. e. a valid POSIX-style string but without explicit rules. > I also uninstalled the database for that test. > > Under these circumstances tzparse() in localtime.c will return an error > because it fails to open a default rules file. From what I remember I > would say that POSIX demands that the US rules should be applied instead. > > POSIX.1 is not US-centric here; it says that the behavior in this case > is implementation-defined. The rationale (POSIX 1003.1-1996 section > B.8.1.1 page 493 lines 5609-5612) says ``An implementation may provide > those rules [i.e. the DST rules not explicitly specified by the user] OK, I'll never use the word POSIX again. ;-) My information is only second hand. > Anyway, "CET-1CEST-2" is perfectly POSIX-compliant and the library should > not return an error then. > > Yes. My reading of POSIX.1 is that the implementation is allowed to > guess the DST rules, but it's not allowed to fail. I agree. A popular German Unix guide recommends "CET-1CEST-2" as the default TZ setting for Germany, German HP-UX distributions use it to (well, with "MET" instead of "CET"). > The GNU libc handles this case by assuming an implicit rule of > "M4.1.0,M10.5.0" (commented as "US Federal Law"). My solution is somewhat > different: I generated a header "new_york.h" > > Both solutions have problems. The first mishandles old dates; the > second assumes the New York City DST rules, whereas it'd be better to > assume only the US rules. Implementing the plain US rules (back to > 1918) would be better; can you do this? Do you mean writing a rules file for that case (which could be compiled and hardcoded into the library)? Actually I even have problems with that solution. I think we had better leave DST alone if no rules are available. Guessing rules always means to do exactly the wrong thing for half of the world, assuming rules that are suitable for the northern hemisphere means to discriminate the southern hemisphere. Correct me if I'm wrong, but isn't it possible to explicitely mark that question as undecidable by setting tm->tm_isdst resp. the variable daylight to -1? Collecting back data which will most probably provide wrong results looks a little ridiculous to me. What should we do when time_t grows 64 bits big? Guess if Alexander arrived one hour early at Issos because the Greek had DST and the Persians hadn't? > > In zic.c, the analysis of the return value of > system("yearistype ...") assumes a certain structure of that return value. > > That's clearly a portability bug; here's a patch. Fine. > +#if HAVE_SYS_WAIT_H - 0 > +#include <sys/wait.h> /* for WIFEXITED and WEXITSTATUS */ > +#endif /* HAVE_SYS_WAIT_H - 0 */ > + > +#ifndef WIFEXITED > +#define WIFEXITED(status) (((status) & 0xff) == 0) > +#endif /* !defined WIFEXITED */ > +#ifndef WEXITSTATUS > +#define WEXITSTATUS(status) (((status) >> 8) & 0xff) > +#endif /* !defined WEXITSTATUS */ Will that work on BSD systems with a union wait? system() returns int, so what does BSD recommend to get the status bits? Sorry, I don't know, I just want to point out a possible problem. Ciao Guido -- http://stud.uni-sb.de/~gufl0000 mailto:gufl0000@stud.uni-sb.de

1 0