- 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 7, 1999

July 7, 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