- tz - lists.iana.org

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

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