- tz - lists.iana.org

Time Zone Converter in Perl
by Dr. Peter Eifler July 27, 2000

July 27, 2000

I would like to write a time zone converter in Perl using your incredible time zone database. Where can I find some access code and installing instructions? Thanks for your help! Peter Eifler (from Germany)

1 0

RE: tzcode standard C patch
by Olson, Arthur David (NCI) July 27, 2000

July 27, 2000

...You shouldn't need that patch; all you > should need to do is to compile with -DHAVE_STRERROR=1. That being > said, I think HAVE_STRERROR should default to 1 these days; strerror > has been in the C standard for more than a decade and I no longer have > access to any hosts that lack strerror. > > Here's a proposed patch... > Another approach would be to just drop the two pieces of code that are conditioned on HAVE_STRERROR from zic.c. --ado

2 1

None
by firoz.vasi＠crt.com July 26, 2000

July 26, 2000

I need help with getting data/information files for certain zones on NeXTSTEP. They are not the standard GMT+5, GMT+6, etc. files, but need it for half hour changes. I guess GMT+55 (for GMT + 5.30). These files I believe go under zoneinfo. I would really appreciate it if someone could send me step by step instructions on how to do this, or send me the data files themselves after running zic or whatever. I tried to run zic, but came up with all kinds of compiler and data errors. Thanks Firoz Vasi

2 1

FW: tzcode standard C patch
by Olson, Arthur David (NCI) July 26, 2000

July 26, 2000

Torsten is not on the time zone mailing list; direct replies appropriately. --ado > -----Original Message----- > From: Torsten Duwe [SMTP:duwe@caldera.de] > Sent: Tuesday, July 25, 2000 8:35 AM > To: tz(a)elsie.nci.nih.gov > Cc: duwe(a)caldera.de > Subject: tzcode standard C patch > > Dear Mr. Olson (hope "tz" is a synonym, not a list :-) , > > attached you find the patch we at Caldera are using for quite a while > now to compile the tzcode under Linux, namely with the GNU C library, > version > 2 and up. I strongly believe the old code compiles on other, "tradidional" > Unix-like systems (if it does so at all without changes) because of their > excessive backward compatibility, that the GNU C library intentionally has > not. My manuals (GNU C library and NetBSD C Library) state that > strerror/perror/<errno.h> comply to > > ANSI X3.159-1989 (``ANSI C'') > BSD 4.3, POSIX, X/OPEN . > > I have carefully made the changes only to the "#ifdef unix" case, but I > think > it is applicable in general. > > Thank you for your attention, > > Torsten Duwe > > --- zic.c~ Thu May 28 15:56:07 1998 > +++ zic.c Mon Oct 12 17:04:02 1998 > @@ -9,6 +9,7 @@ > #include "tzfile.h" > #ifdef unix > #include "sys/stat.h" /* for umask manifest > constants */ > +#include <errno.h> > #endif /* defined unix */ > > /* > @@ -377,7 +378,9 @@ > strerror(errnum) > int errnum; > { > +#ifndef unix > extern char * sys_errlist[]; > +#endif > extern int sys_nerr; > > return (errnum > 0 && errnum <= sys_nerr) ?

3 2

FW: Israel Timezone -- Changes for 2000-2002 and New Dates for 20 03-2004
by Olson, Arthur David (NCI) July 25, 2000

July 25, 2000

Ephraim is not on the time zone mailing list; direct replies appropriately. --ado > -----Original Message----- > From: Ephraim Silverberg [SMTP:ephraim@cs.huji.ac.il] > Sent: Tuesday, July 25, 2000 4:09 AM > To: tz(a)elsie.nci.nih.gov > Cc: eggert(a)twinsun.com; Olson, Arthur David (NCI); rmcdow(a)enteles.com > Subject: Israel Timezone -- Changes for 2000-2002 and New Dates for > 2003-2004 > > On July 19, 2000, the Israeli Parliament [Knesset] has passed a statute > amending the dates for 2000-2002 and setting new dates for 2003-2004. > > Attached are the context diffs of the 'asia' file of tzdata2000d.tar.gz > showing the start/end dates of Daylight Savings Time in Israel from 2000 > until 2004 inclusive. > -----------------------------------CUT-HERE------------------------------- > ----- > *** asia Tue Mar 14 16:39:25 2000 > --- asia.new Tue Jul 25 10:59:59 2000 > *************** > *** 526,532 **** > Rule Zion 1988 only - Sep 3 0:00 0 > S > > # From Ephraim Silverberg <ephraim(a)cs.huji.ac.il> > ! # (1997-03-04, 1998-03-16, 1998-12-28, and 2000-01-17): > > # According to the Office of the Secretary General of the Ministry of > # Interior, there is NO set rule for Daylight-Savings/Standard time > changes. > --- 526,532 ---- > Rule Zion 1988 only - Sep 3 0:00 0 > S > > # From Ephraim Silverberg <ephraim(a)cs.huji.ac.il> > ! # (1997-03-04, 1998-03-16, 1998-12-28, 2000-01-17 and 2000-07-25): > > # According to the Office of the Secretary General of the Ministry of > # Interior, there is NO set rule for Daylight-Savings/Standard time > changes. > *************** > *** 537,550 **** > # Saturday night from midnight daylight savings time to 11 p.m. standard > # time. 1996 is an exception to this rule where the change back to > standard > # time took place on Sunday night instead of Saturday night to avoid > ! # conflicts with the Jewish New Year. Starting in 1999, the change to > ! # daylight savings time will still be on a Friday morning but from > # 2 a.m. IST to 3 a.m. IDT; furthermore, the change back to standard > time > ! # will now also be on a Friday morning from 2 a.m. IDT to 1 a.m. IST for > ! # 1999 only. In the years from 2000 to 2002, the change back will be > from > ! # 2 a.m. IDT to 1 a.m. IST the morning after the Jewish festival of > ! # Shmini Atzeret (i.e. the morning of the 23rd of Tishrei in the lunar > ! # Hebrew calendar). > > # Rule NAME FROM TO TYPE IN ON AT SAVE > LETTER/S > Rule Zion 1989 only - Apr 30 0:00 1:00 > D > --- 537,555 ---- > # Saturday night from midnight daylight savings time to 11 p.m. standard > # time. 1996 is an exception to this rule where the change back to > standard > # time took place on Sunday night instead of Saturday night to avoid > ! # conflicts with the Jewish New Year. In 1999, the change to > ! # daylight savings time was still be on a Friday morning but from > # 2 a.m. IST to 3 a.m. IDT; furthermore, the change back to standard > time > ! # was also be on a Friday morning from 2 a.m. IDT to 1 a.m. IST for > ! # 1999 only. In the year 2000, the change to daylight savings time was > ! # similar to 1999, but although the change back will be on a Friday, it > ! # will take place from 1 a.m. IDT to midnight IST. Starting in 2001, > all > ! # changes to/from will take place at 1 a.m. old time, but now there is > no > ! # rule as to what day of the week it will take place in as the start > date > ! # (except in 2003) is the night after the Passover Seder (i.e. the eve > ! # of the 16th of Nisan in the lunar Hebrew calendar) and the end date > ! # (except in 2002) is three nights before Yom Kippur [Day of Atonement] > ! # (the eve of the 7th of Tishrei in the lunar Hebrew calendar). > > # Rule NAME FROM TO TYPE IN ON AT SAVE > LETTER/S > Rule Zion 1989 only - Apr 30 0:00 1:00 > D > *************** > *** 592,620 **** > Rule Zion 1999 only - Apr 2 2:00 1:00 > D > Rule Zion 1999 only - Sep 3 2:00 0 > S > > ! # Minister of Interior, Natan Sharansky, has announced the dates for > ! # the years 2000-2002. However, sources inside the ministry have noted > ! # that the end date of 2000 and both dates of 2001-2002 should be > regarded > ! # as tentative pending final approval. > # > ! # The official announcement for the years 2000-2002 can be viewed at: > # > ! # ftp://ftp.huji.ac.il/pub/tz/announcements/2000-2002.ps.gz > > # Rule NAME FROM TO TYPE IN ON AT SAVE > LETTER/S > Rule Zion 2000 only - Apr 14 2:00 1:00 > D > ! Rule Zion 2000 only - Oct 22 2:00 0 > S > ! Rule Zion 2001 only - Apr 6 2:00 1:00 > D > ! Rule Zion 2001 only - Oct 10 2:00 0 > S > ! Rule Zion 2002 only - Mar 29 2:00 1:00 > D > ! Rule Zion 2002 only - Sep 29 2:00 0 > S > > # From Paul Eggert (2000-01-17): > ! # Here are guesses for rules after 2002. > # They are probably wrong, but they are more likely than no DST at all. > # Rule NAME FROM TO TYPE IN ON AT SAVE > LETTER/S > ! Rule Zion 2003 max - Mar Fri>=25 2:00 1:00 > D > ! Rule Zion 2003 max - Oct 1 2:00 0 > S > > # Zone NAME GMTOFF RULES FORMAT [UNTIL] > Zone Asia/Jerusalem 2:20:56 - LMT 1880 > --- 597,633 ---- > Rule Zion 1999 only - Apr 2 2:00 1:00 > D > Rule Zion 1999 only - Sep 3 2:00 0 > S > > ! # The Knesset Interior Committee has changed the dates for 2000 for > ! # the third time in just over a year and have set new dates for the > ! # years 2001-2004 as well. > # > ! # The official announcement for the start date of 2000 can be viewed at: > # > ! # ftp://ftp.huji.ac.il/pub/tz/announcements/2000-start.ps.gz > ! # > ! # The official announcement for the end date of 2000 and the dates > ! # for the years 2001-2004 can be viewed at: > ! # > ! # ftp://ftp.huji.ac.il/pub/tz/announcements/2000-2004.ps.gz > > # Rule NAME FROM TO TYPE IN ON AT SAVE > LETTER/S > Rule Zion 2000 only - Apr 14 2:00 1:00 > D > ! Rule Zion 2000 only - Oct 6 1:00 0 > S > ! Rule Zion 2001 only - Apr 9 1:00 1:00 > D > ! Rule Zion 2001 only - Sep 24 1:00 0 > S > ! Rule Zion 2002 only - Mar 29 1:00 1:00 > D > ! Rule Zion 2002 only - Oct 7 1:00 0 > S > ! Rule Zion 2003 only - Mar 28 1:00 1:00 > D > ! Rule Zion 2003 only - Oct 3 1:00 0 > S > ! Rule Zion 2004 only - Apr 7 1:00 1:00 > D > ! Rule Zion 2004 only - Sep 22 1:00 0 > S > > # From Paul Eggert (2000-01-17): > ! # Here are guesses for rules after 2004. > # They are probably wrong, but they are more likely than no DST at all. > # Rule NAME FROM TO TYPE IN ON AT SAVE > LETTER/S > ! Rule Zion 2005 max - Apr 1 1:00 1:00 > D > ! Rule Zion 2005 max - Oct 1 1:00 0 > S > > # Zone NAME GMTOFF RULES FORMAT [UNTIL] > Zone Asia/Jerusalem 2:20:56 - LMT 1880 > ----------------------------------UNTIL-HERE------------------------------ > ----- > > __________________________________________________________________________ > _ > Ephraim Silverberg, CSE System Group, Phone number: > 972-2-6585521 > Hebrew University, Jerusalem, Israel. Fax number: > 972-2-6585439 > WWW: http://www.cs.huji.ac.il/~ephraim E-mail: > ephraim(a)cse.huji.ac.il

1 0

tzcode standard C patch
by Torsten Duwe July 25, 2000

July 25, 2000

Dear Mr. Olson (hope "tz" is a synonym, not a list :-) , attached you find the patch we at Caldera are using for quite a while now to compile the tzcode under Linux, namely with the GNU C library, version 2 and up. I strongly believe the old code compiles on other, "tradidional" Unix-like systems (if it does so at all without changes) because of their excessive backward compatibility, that the GNU C library intentionally has not. My manuals (GNU C library and NetBSD C Library) state that strerror/perror/<errno.h> comply to ANSI X3.159-1989 (``ANSI C'') BSD 4.3, POSIX, X/OPEN . I have carefully made the changes only to the "#ifdef unix" case, but I think it is applicable in general. Thank you for your attention, Torsten Duwe --- zic.c~ Thu May 28 15:56:07 1998 +++ zic.c Mon Oct 12 17:04:02 1998 @@ -9,6 +9,7 @@ #include "tzfile.h" #ifdef unix #include "sys/stat.h" /* for umask manifest constants */ +#include <errno.h> #endif /* defined unix */ /* @@ -377,7 +378,9 @@ strerror(errnum) int errnum; { +#ifndef unix extern char * sys_errlist[]; +#endif extern int sys_nerr; return (errnum > 0 && errnum <= sys_nerr) ?

1 0

Israel Timezone -- Changes for 2000-2002 and New Dates for 2003-2004
by Ephraim Silverberg July 25, 2000

July 25, 2000

On July 19, 2000, the Israeli Parliament [Knesset] has passed a statute amending the dates for 2000-2002 and setting new dates for 2003-2004. Attached are the context diffs of the 'asia' file of tzdata2000d.tar.gz showing the start/end dates of Daylight Savings Time in Israel from 2000 until 2004 inclusive. -----------------------------------CUT-HERE------------------------------------ *** asia Tue Mar 14 16:39:25 2000 --- asia.new Tue Jul 25 10:59:59 2000 *************** *** 526,532 **** Rule Zion 1988 only - Sep 3 0:00 0 S # From Ephraim Silverberg <ephraim(a)cs.huji.ac.il> ! # (1997-03-04, 1998-03-16, 1998-12-28, and 2000-01-17): # According to the Office of the Secretary General of the Ministry of # Interior, there is NO set rule for Daylight-Savings/Standard time changes. --- 526,532 ---- Rule Zion 1988 only - Sep 3 0:00 0 S # From Ephraim Silverberg <ephraim(a)cs.huji.ac.il> ! # (1997-03-04, 1998-03-16, 1998-12-28, 2000-01-17 and 2000-07-25): # According to the Office of the Secretary General of the Ministry of # Interior, there is NO set rule for Daylight-Savings/Standard time changes. *************** *** 537,550 **** # Saturday night from midnight daylight savings time to 11 p.m. standard # time. 1996 is an exception to this rule where the change back to standard # time took place on Sunday night instead of Saturday night to avoid ! # conflicts with the Jewish New Year. Starting in 1999, the change to ! # daylight savings time will still be on a Friday morning but from # 2 a.m. IST to 3 a.m. IDT; furthermore, the change back to standard time ! # will now also be on a Friday morning from 2 a.m. IDT to 1 a.m. IST for ! # 1999 only. In the years from 2000 to 2002, the change back will be from ! # 2 a.m. IDT to 1 a.m. IST the morning after the Jewish festival of ! # Shmini Atzeret (i.e. the morning of the 23rd of Tishrei in the lunar ! # Hebrew calendar). # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Zion 1989 only - Apr 30 0:00 1:00 D --- 537,555 ---- # Saturday night from midnight daylight savings time to 11 p.m. standard # time. 1996 is an exception to this rule where the change back to standard # time took place on Sunday night instead of Saturday night to avoid ! # conflicts with the Jewish New Year. In 1999, the change to ! # daylight savings time was still be on a Friday morning but from # 2 a.m. IST to 3 a.m. IDT; furthermore, the change back to standard time ! # was also be on a Friday morning from 2 a.m. IDT to 1 a.m. IST for ! # 1999 only. In the year 2000, the change to daylight savings time was ! # similar to 1999, but although the change back will be on a Friday, it ! # will take place from 1 a.m. IDT to midnight IST. Starting in 2001, all ! # changes to/from will take place at 1 a.m. old time, but now there is no ! # rule as to what day of the week it will take place in as the start date ! # (except in 2003) is the night after the Passover Seder (i.e. the eve ! # of the 16th of Nisan in the lunar Hebrew calendar) and the end date ! # (except in 2002) is three nights before Yom Kippur [Day of Atonement] ! # (the eve of the 7th of Tishrei in the lunar Hebrew calendar). # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Zion 1989 only - Apr 30 0:00 1:00 D *************** *** 592,620 **** Rule Zion 1999 only - Apr 2 2:00 1:00 D Rule Zion 1999 only - Sep 3 2:00 0 S ! # Minister of Interior, Natan Sharansky, has announced the dates for ! # the years 2000-2002. However, sources inside the ministry have noted ! # that the end date of 2000 and both dates of 2001-2002 should be regarded ! # as tentative pending final approval. # ! # The official announcement for the years 2000-2002 can be viewed at: # ! # ftp://ftp.huji.ac.il/pub/tz/announcements/2000-2002.ps.gz # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Zion 2000 only - Apr 14 2:00 1:00 D ! Rule Zion 2000 only - Oct 22 2:00 0 S ! Rule Zion 2001 only - Apr 6 2:00 1:00 D ! Rule Zion 2001 only - Oct 10 2:00 0 S ! Rule Zion 2002 only - Mar 29 2:00 1:00 D ! Rule Zion 2002 only - Sep 29 2:00 0 S # From Paul Eggert (2000-01-17): ! # Here are guesses for rules after 2002. # They are probably wrong, but they are more likely than no DST at all. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S ! Rule Zion 2003 max - Mar Fri>=25 2:00 1:00 D ! Rule Zion 2003 max - Oct 1 2:00 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Jerusalem 2:20:56 - LMT 1880 --- 597,633 ---- Rule Zion 1999 only - Apr 2 2:00 1:00 D Rule Zion 1999 only - Sep 3 2:00 0 S ! # The Knesset Interior Committee has changed the dates for 2000 for ! # the third time in just over a year and have set new dates for the ! # years 2001-2004 as well. # ! # The official announcement for the start date of 2000 can be viewed at: # ! # ftp://ftp.huji.ac.il/pub/tz/announcements/2000-start.ps.gz ! # ! # The official announcement for the end date of 2000 and the dates ! # for the years 2001-2004 can be viewed at: ! # ! # ftp://ftp.huji.ac.il/pub/tz/announcements/2000-2004.ps.gz # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Zion 2000 only - Apr 14 2:00 1:00 D ! Rule Zion 2000 only - Oct 6 1:00 0 S ! Rule Zion 2001 only - Apr 9 1:00 1:00 D ! Rule Zion 2001 only - Sep 24 1:00 0 S ! Rule Zion 2002 only - Mar 29 1:00 1:00 D ! Rule Zion 2002 only - Oct 7 1:00 0 S ! Rule Zion 2003 only - Mar 28 1:00 1:00 D ! Rule Zion 2003 only - Oct 3 1:00 0 S ! Rule Zion 2004 only - Apr 7 1:00 1:00 D ! Rule Zion 2004 only - Sep 22 1:00 0 S # From Paul Eggert (2000-01-17): ! # Here are guesses for rules after 2004. # They are probably wrong, but they are more likely than no DST at all. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S ! Rule Zion 2005 max - Apr 1 1:00 1:00 D ! Rule Zion 2005 max - Oct 1 1:00 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Jerusalem 2:20:56 - LMT 1880 ----------------------------------UNTIL-HERE----------------------------------- ___________________________________________________________________________ Ephraim Silverberg, CSE System Group, Phone number: 972-2-6585521 Hebrew University, Jerusalem, Israel. Fax number: 972-2-6585439 WWW: http://www.cs.huji.ac.il/~ephraim E-mail: ephraim(a)cse.huji.ac.il

1 0

archive
by McKinstry, Alastair July 19, 2000

July 19, 2000

get latest/781 get latest/782 get latest/783

1 0

archive
by McKinstry, Alastair July 19, 2000

July 19, 2000

ls latest

1 0

archive help
by McKinstry, Alastair July 19, 2000

July 19, 2000

1 0

A mystery of Earth's wobble solved: It's the ocean (fwd)
by Markus Kuhn July 18, 2000

July 18, 2000

Here something for those time geeks interested in the cause of the difference between UT0 and UT1. Markus

1 0

Thank you, and a brief note on time zone offsets
by Russ Allbery July 16, 2000

July 16, 2000

I've just spent a very enjoyable and interesting part of a couple of days reading the full archives of the tz mailing list. Thank you, all! I now know considerably more about a rather fascinating topic than I did before. (And having the full archives going back fifteen years all available, in a format that my mail reader can even thread, sort, and score for me, is very nice; I'll have to bear that in mind for any mailing lists I may run in the future.) In partial thanks for all of the good information, here's a gotcha that I don't believe has been mentioned on this mailing list previously. There has been some previous discussion about the preferred form of representing time zone offsets; RFC 822 uses [+-]HHMM, while some other formats put a colon between the hours and the minutes. The previous discussion didn't seem to turn up much reason for preferring one over the other, and some general preference for leaving out the colon for a shorter format. I became interested in this whole topic in the process of standardizing INN's internal generation of Date headers. When I started on that, I discovered that someone who had been (re-)implementing support for generation of Date headers in the local time zone rather than UTC had taken the offset from UTC in seconds and, to convert to an offset, simply divided by 36! Thankfully, this never made it into a released version (and it's now fixed), but the RFC 822 format, combined with the relative scarcity of time zones whose offsets aren't even numbers of hours, actively encourages this mistake. Seconds offset from GMT divided by 36 and printed out as a number is actually correct for hour offset time zones, but gives e.g. -0250 instead of -0230 for other time zones, because rather than HHMM, it's actually fractional hours multiplied by 100. Had RFC 822 required the colon between hours and minutes, it would have made it clear that they were two separate numbers and would probably have prevented this mistake. As always with standards, it's best if a cursory inspection of the results suggests the right implementation, or at least doesn't suggest a mistaken implementation, as a lot of code gets written without actually referring to the real standard. :/ -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

help
by McKinstry, Alastair July 13, 2000

July 13, 2000

subscribe -- Alastair McKinstry - AlphaServer SC Engineering Compaq Computer Corporation, Ballybrit Business Park, Galway, Ireland Phone: +35391 754521 FAX +353 91 754435 <alastair.mckinstry(a)compaq.com>

1 0

Bulletin C number 20 (fwd)
by Markus Kuhn July 12, 2000

July 12, 2000

1 0

Bulletin C number 20
by iers＠hpopa.obspm.fr July 12, 2000

July 12, 2000

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 2000 Bulletin C 20 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 2000. 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

Re: Leap Second Report (fwd)
by Bradley White July 7, 2000

July 7, 2000

The Report of the URSI Commission J Working Group on the Leap Second read: > Appendix III. "Standard Reply" to queries concerning the questionnaire > > The response one person sent me is below, and it concerns Network Time > Protocol (NTP), which uses the internet to transfer time. > >> If leap seconds went away, the NTP community would worship the ground you >> walk on. Leap secs introduce a manual discontinuity in the NTP time scale. >> It takes a while to propagate leap secs through the hierarchy. While I concur on the unfortunate way in which NTP time stamps are encoded, I was running a sub-tree of NTP servers on an ado "right_only" system back in 1989 that, with the addition of a single time2posix() call, sailed through leap seconds without a hiccup (and without the need for any leap-second warning), so, I would proffer that leap seconds are not as much of a problem for NTP as many people seem to believe. Of course, leap-second warnings need to be replaced with the timely distribution of new ado zoneinfo data (which would also help with the ever changing summertime rules). I'm surprised that after all these years we do not have such a system in place, even if it was just a new DNS record type tied to names like New_York.America.zoneinfo.org. Bradley

1 0

Re: Leap Second Report
by Paul Eggert July 5, 2000

July 5, 2000

Date: Wed, 5 Jul 2000 14:32:15 GMT From: Demetrios N Matsakis <dnm(a)orion.usno.navy.mil> Report of the URSI Commission J Working Group on the Leap Second Just to put that report in its bureaucratic context: URSI is the International Union of Radio Science, a nongovernmental organization under the International Council for Science (ICSU). Commission J focuses on radio astronomy and remote sensing of celestial objects. Commission J set up the Working Group on the Leap Second in August of last year. Its job is to study the effect of halting leap second insertions into UTC, as proposed by McCarthy and Klepczynski. ICSU home page: http://www.icsu.org/ URSI home page: http://www.intec.rug.ac.be/Research/Projects/ursi/welcome.html Commission J info: http://www.intec.rug.ac.be/Research/Projects/ursi/Commissions.html Abstract of McCarthy & Klepczynski paper: http://www.gisdevelopment.net/reference/scie/s_t_41_50.htm#47

1 0

Leap Second Report (fwd)
by Markus Kuhn July 5, 2000

July 5, 2000

You might remember the USNO survey on the redefinition of UTC a few months ago. Here is their report on the results, which I guess might be of interest to some here. [My own reply then in a nutshell was not to abandon leap seconds, but perhaps to announce them much longer in advance (say 25 years), even if this means |UTC-UT1| > 900 ms sometimes temporarily.] Markus ------- Forwarded Message Date: Wed, 5 Jul 2000 14:23:34 GMT From: Demetrios N Matsakis <dnm(a)orion.usno.navy.mil> Subject: Leap Second Report Dear Respondee, Thank you for having responded to, or somehow been connected with, our questionnaire concerning the effects of a redefinition of UTC. If you are interested in pursuing this issue, we welcome you to join our listserv "chat group", http://clockdev.usno.navy.mil/archives/leapsecs.html. Demetrios Matsakis *************************************************************************** Report of the URSI Commission J Working Group on the Leap Second Date: July 2, 2000 Abstract and Conclusions An e-mail survey to find possible adverse effects of a redefinition of UTC has identified some possibly expensive or unsolvable problems involving software rewriting or checking, which are listed below. Although it was not possible to quantify the financial scale of resolving the software problems, the largest expenses appear to be for satellite systems, of which one estimate of several hundred thousand dollars was supplied. The quantity and quality of the responses opposed to a change indicate that those who favor any change must be prepared to make a very convincing argument to people and groups who initially will disagree with them. To further discuss this issue and inform the community of any developments, an archived electronic listserv has been set up. Anyone wishing to join can do so using http://clockdev.usno.navy.mil/archives/leapsecs.html. Introduction UTC (Coordinated Universal Time), which the public commonly confuses with Greenwich Mean Time, is computed by occasionally adding leap seconds to International Atomic Time (TAI). Since 1972, these leap seconds have been added on December 31 or June 30, at the rate of about one every 18 months, and serve to keep atomic time in step with the Earth's rotation. Although it is recommended that users use only TAI or UTC, as their needs indicate, many major navigation system have used times offset from TAI by fixed amounts. The most important of these is GPS, which is offset by 19 seconds from TAI. A segment of the international timing community has proposed a revision of the definition of UTC to avoid the discontinuities due to intermittent leap seconds. A discussion of the motivations for a change and of possible solutions has been published by McCarthy and Klepczynski in the Innovations Section of the November, 1999 issue of GPS World. The authors consider the most significant reason for a change to be keeping spread-spectrum communication systems and satellite navigation systems compatible with each other and with civil times. Another reason is the emerging need in the financial community to keep all computer time-stamps synchronized. In order to survey the effects of any action, an URSI Commission J Working Group (WG) was formed, whose purpose was to prepare this report and propose further actions. Methodology A questionnaire (Appendix I) was distributed as widely as seemed appropriate (Appendix II). The goal of the questionnaire was to find and categorize those operations that would be adversely affected should a change in UTC's computation be made. The questionnaire focused on the possibility of simply inserting no new leap seconds, although alternative solutions were also solicited. Over 200 responses were received, and no effort was made to separate the responses of URSI members from those of nonmembers. The principal object of the questionnaire was to find what systems would be adversely affected should a change be made in leap second procedures rather than to convince users of the need for a change or to take a vote. However, so many queries on these matters were received that a "standard reply" (Appendix III) was developed and distributed as appropriate. In the spirit of full disclosure, the number of responses in each category is given, but we caution that this was by no means an unbiased sampling of all who would be affected by the change. All responses were counted only once, with preference to the most practical grounds for objection. About half the responses that were received were opposed to any change, while one-fourth were in favor of a change, and one-fourth indifferent. I. Responses Opposed to Changes in the Status Quo A. The expense of rewriting software. Five responses suggested that contractors would have to be hired to scrutinize and adapt large amounts of code for operational satellite systems. Efforts were made to contact these responders for specific dollar amounts, and one off-the-cuff estimate of "several $100,000" was received. The impact on such systems would be lessened if any decision to redefine UTC were announced several years in advance. Twenty-six others indicated that software would be a serious problem - a very few of these were from people who did not seem to understand the proposal. There were 9 responses involving telescope control; one of these, from the Keck Observatory, provided a rough estimate of a few programmer- months. Others pointed out the problems computing eclipses and occultations, for telescope pointing by amateurs, or with code they had themselves written for professional-level projects such as speckle interferometry. One observatory indicated its station clock can not accommodate a large UT1-UTC correction. Fourteen more indicated that software issues would be a problem, but that they are probably solvable. Some of these actually indicated support for the change. B. Inherent inability to rewrite software to allow for |UT1-UTC| exceeding .9 seconds. Ten responses involved navigational software. Taking the example of a software product of the US Naval Observatory (USNO), pilots and sailors are given the option to input UT1-UTC. However, it is expected that many users would not understand this and enter 0, leading to noticeable errors within a decade. These are similar to the telescope-control problems covered above, except that one could not and should not expect the general public to ever understand these issues. Problems amateur astronomers might have are also included here, and were brought up by many responders in other contexts. One of the problems anticipated is that UT1-UTC could be applied with the wrong sign, just as the leap second is occasionally applied with the wrong sign. An example of "buffer overflow" problem would happen in NIST's WWV, WWVH and WWWB transmissions, which do not allow enough space for |UT1-UTC| to exceed .9 sec. Any users of these broadcasts who might need this information and who are unaware of the problem, decoding in hardware, or relying on old software would be adversely affected. Under the best of future circumstances only the sub-second (tenths) digit would be available, requiring the user to keep track of the digits to the left of the decimal point. Not tabulated is an informal comment seriously made to the Working Group's Chairman, by a respected and competent scientist from a non-western nation, that astrologers would be adversely affected. C. Philosophical Objections Eight thought this would confuse or antagonize the public, religious authorities, or even scientists - in essence because solar time is "true time". (In contrast, one responder in favor of a change thought this would help educate the public to the fact that Earth rotation is not "true" time). Three pointed out that legal complications might occur in countries where laws are specified in terms of solar time, or GMT (which has not existed for thirty years). Although one of these responders feared governments would not follow the scientist's lead, we find it difficult to believe that governments would, on their own, choose to add leap seconds. Others thought that any legal system flexible enough to handle daylight savings time and the past abandonment of GMT in favor of UTC would easily accommodate a seamless change in UTC's computation, especially if no other time standard were available. Some of the history of legal issues concerning past changes in time definition can be found in the book "Greenwich Time and Longitude" by Derek Howse. Three thought we should not adopt a system which will fail in the long run, even if that is a very distant time in the future. (It could be pointed out that all current time systems will eventually fail. Well before 2050 we could be routinely adding more than one leap second per year, and when we reach the point where a day is 48 hours long we would have to add a leap second every second. Even the Gregorian calendar will eventually need revision because in a few million years the Earth will rotate less than 365 times per year, and leap days will not be necessary.) Two thought this would deprive the timing community of free publicity when leap seconds are inserted. Thirty-eight expressed opposition, but gave no specific reason. Eleven of those also indicated that a problem would exist with their system, but did not specify it. Some of these pointed out that TAI was readily available, or indicated that they had seen no justification for a change. (We had intentionally provided no justification in the initial questionnaire, but two responders replied that they still believed there was not enough reason to change even after having read "standard response".) Four were against it because they thought problems would happen if some systems did not use the new system, and because they thought one would have to separate analyses based upon whether data were recorded with the current system or the old system. (We believe these to be based upon a misunderstanding of the "no new leap seconds" proposal, but entirely possible if the more drastic measure of re-defining SI, the International Second, were adopted.) II. Alternative Suggestions Five suggested that it would be better to redefine the second to be longer, add 1 second every 18 months forever, change on leap years or century-ends, or change when the number exceeded a fixed amount. These possibilities are also discussed in the GPS World Article. A suggestion was received to add enough "negative leap seconds" to bring UTC in line with GPS. However, a different responder pointed out that many of NASA's programs assume UT1-UTC always grows and that problems would happen with any change that would sometimes lead to a "negative leap second". (According to Dennis McCarthy of the USNO, this is possible even with the current system, but unlikely). It was also pointed out that rubidium atomic fountains or optical standards could lead to a redefinition of the second using an element other than cesium. If so, it could be redefined using a scale factor of sufficient magnitude to avoid the short-term need for leap seconds (As noted in the GPS World article, such a change would alter the values of those physical quantities that depend upon time.) One suggested that a redefined UTC should have a new name. III. Responses in favor of changing the current leap second procedures Forty-eight responses in favor were received, several from people who experienced minor problems now in handling leap seconds, such as confusion due to GPS time being currently 13 seconds offset from UTC and computer errors at the time of the leap seconds. Along with responses based upon reasons already covered in the GPS World Article, there were also three from the highly undersampled group of computer programmers, which pointed out the growing need to synchronize diverse computers to one second accuracy and the difficulties of doing so in an when dates of future leap seconds were unpredictable. Many of the responses indicated that periodic addition of leap seconds on a scheduled basis would also be acceptable. One of the responders, who was opposed to a change, suggested that leap seconds were not a problem because computer users could program an automatic extraction of the needed information from some publicly available source; however it must be pointed out that no one can guarantee that a given file, whether it be for leap seconds or for daily values of UT1-UTC (see part IV, below), will remain forever available in a given format or given IP address. Four responses were from people who indicated that the convenience in not having to update files every 18 months outweighed the expense and problems rewriting software. One of these suggested the use of sufficient negative leap seconds to bring UTC in line with TAI, and several noted that UT1-users easily incorporate the offsets due to time zones and daylight time. IV. Other Responses Forty-seven responders checked the "indifferent" option. Most indicated that there would be no problems with their system, or that the problems were small enough that they were indifferent to a change. Seven other responders indicated that the change would be okay if they could somehow reliably obtain UT1-UTC. (The USNO, as a sub-bureau of the IERS, freely provides this information on its web site, http://www. maia.usno.navy.mil, and via weekly emailings. Other organizations also provide this information.) Some responses tabulated here were phrased in the negative because the responders were apparently unaware that the information was available. One responder was concerned that the GPS system itself would be degraded for this reason, however this is not the case because GPS currently uses UT1-UTC values derived from USNO products. ________________________________________________________________________ Appendix I. Questionnaire It is being proposed to change the definition of Coordinated Universal Time (UTC) regarding the insertion of leap seconds, possibly even eliminating their use. Leap seconds are introduced so as to keep UTC synchronized (within 0.9 s) to the time scale determined from the Earth's rotation. Should no new leap seconds be inserted, solar time will diverge from atomic time at the rate of about 2 seconds every 3 years, and after about a century |UT1-UTC| would exceed 1 minute. Although no fundamental problems are anticipated, it is very likely that Y2K-like problems may result in software that assumes UT1=UTC, or |UT1-UTC|< some value, or whose input/output records use a field size that can only accommodate |UT1-UTC| values up to one second. To gather information, an URSI Commission J Working Group was formed, consisting of Don Backer, Wim. N. Brouw, Barry Clark, Irwin Shapiro, Ir. E. Van Lil, with Demetrios Matsakis being the chair. We would like to ask you to consult with the members of your institute who currently deal with UT1-UTC, and give us a considered response to the following two questions: A. If the appropriate international bodies decide to eliminate the insertion of new leap seconds, would you foresee any practical problems for your institution/instrument/observations? no ____ * yes ___ * possibly ____ (* please explain any known or possible problems) B. Would you be in favor of such a proposal? yes ____ no ____ indifferent ___ have better idea ___ (feel free to comment) C. Is there anyone else you would recommend we contact? (feel free to forward this email directly) I would appreciate your assistance, and a response by January 15 to dnm(a)orion.usno.navy.mil. I am attaching a list of institutions and persons contacted, except for 931 institutions whose emails were obtained from the AAS. I would like to apologize to anyone contacted twice, but also appreciate it if you would forward this email to anyone we have missed. Also, if you are an URSI Commission J national chair, we would appreciate your forwarding this email to your complete membership and in particular to the directors of observatories. Sincerely, Demetrios Matsakis ________________________________________________________________________ Dr. Demetrios N. Matsakis Director, Time Service Department (202) 762-1587 DSN 762-1587 U. S. Naval Observatory FAX (202) 762-1511 3450 Massachusetts Avenue NW dnm(a)orion.usno.navy.mil Washington DC, USA 20392-5420 ________________________________________________________________________ Appendix II. Distribution List Efforts were made to conduct an international survey, and responses were received from Europe, Japan, China, Australia, Canada, Russia, Saudi Arabia, Brazil, and other countries. The majority of the responses, however, were from the U.S. Commercial interests, such as satellite companies, were highly undersampled. The questionnaire asked people to forward it to others, and we know the following were contacted: 1. 128 prominent scientists, who were mostly URSI Commission J members and official representatives of institutions associated with URSI. 2. 27 URSI Commission J national chairs. 3. 931 Institutions extracted from a database kept by the American Astronomical Society, including many from outside the United States. Several hundred of those email addresses proved invalid. 4. All on the USNO Series 7 mailing list. 5. All on the "Gazette" mailing list of the International Earth Rotation Service (IERS). This would be expected to include most scientific groups that are directly involved with UT1. 6. One responder who worked in SETI indicated he had forwarded it to SETI circles. 7. The Internet Engineering Task Force's mail exploder. 8. One responder, who was against any change, indicated he had forwarded the questionnaire extensively around Jet Propulsion Labs (JPL). ________________________________________________________________________ Appendix III. "Standard Reply" to queries concerning the questionnaire Thank you for your response, which will be tabulated. Unix-technology willing, we also plan to send a copy of our report all responders. Many people have asked me why there is a move to rethink the leap seconds, with solutions such as (but not limited to) adding no new leap seconds. I unfortunately edited out some of the reasons from early drafts of the questionnaire, because I was afraid that people would not read a long email. Since then, I have developed the following "standard reply": 1.) Many high-tech navigation systems, particularly those using spread-spectrum techniques, can't handle leap seconds very well. GLONASS, the Russian equivalent to GPS, goes off-line for leap second adjustments. Also, problems can occur in interfacing between systems that handle leap seconds differently. There is also the practical problem of inserting a second every year and half - people often do it the wrong way. The response one person sent me is below, and it concerns Network Time Protocol (NTP), which uses the internet to transfer time. > If leap seconds went away, the NTP community would worship the ground you > walk on. Leap secs introduce a manual discontinuity in the NTP time scale. > It takes a while to propagate leap secs through the hierarchy. Leap seconds > are a tremendous headache in the NTP world because they cannot be predicted. > One must set a flag to indicate that one is coming. I think it is a very > true statement that all GPS users would vote against continuing leap seconds, > not just NTP users. Many telecommunications circuits use GPS or atomic clocks > to keep cellular phones in operation, and leap seconds are a nuisance to them > as well. 2.) I also received many comments about the effects on society when UT1 diverges. Note that we are talking about a minute in the next century. Society routinely handles a one-hour switch with every daily savings time, and a half-hour offset if they live at the edge of a time zone. By the time leap seconds add up to an hour, the world will be very different. If we have settled the solar system, a whole new scheme will probably have evolved. Even if we have not changed our system, society has enough slop in its timekeeping that people will slowly shift without even knowing it. More people will start showing up to work at 9:00 AM, and less at 8:30 AM, etc. 3) The "Innovations" section in November's GPS World is on this subject, and discusses other possibilities aside from "no new leap seconds". These are inserting larger discontinuities less frequently, inserting integer leap seconds at predefined times, simply using TAI, and redefining the length of the second. 4) It should be pointed out that UT1-UTC is readily available on the web. The USNO, as a subbureau of the International Rotation Service, makes this information available via a weekly mailing and from a web page at http://www.maia.usno.navy.mil, and other organizations also provide this service. 5) My final comment is not to worry about any "surprise" decisions - before/if the international bodies all decide to do this, it will be fully debated and publicized. My role, here, is simply to gather information. ------- End of Forwarded Message

1 0

Leap Second Report
by Demetrios N Matsakis July 5, 2000

July 5, 2000

Dear Respondee, Thank you for having responded to, or somehow been connected with, our questionnaire concerning the effects of a redefinition of UTC. If you are interested in pursuing this issue, we welcome you to join our listserv "chat group", http://clockdev.usno.navy.mil/archives/leapsecs.html. Demetrios Matsakis *************************************************************************** Report of the URSI Commission J Working Group on the Leap Second Date: July 2, 2000 Abstract and Conclusions An e-mail survey to find possible adverse effects of a redefinition of UTC has identified some possibly expensive or unsolvable problems involving software rewriting or checking, which are listed below. Although it was not possible to quantify the financial scale of resolving the software problems, the largest expenses appear to be for satellite systems, of which one estimate of several hundred thousand dollars was supplied. The quantity and quality of the responses opposed to a change indicate that those who favor any change must be prepared to make a very convincing argument to people and groups who initially will disagree with them. To further discuss this issue and inform the community of any developments, an archived electronic listserv has been set up. Anyone wishing to join can do so using http://clockdev.usno.navy.mil/archives/leapsecs.html. Introduction UTC (Coordinated Universal Time), which the public commonly confuses with Greenwich Mean Time, is computed by occasionally adding leap seconds to International Atomic Time (TAI). Since 1972, these leap seconds have been added on December 31 or June 30, at the rate of about one every 18 months, and serve to keep atomic time in step with the Earth's rotation. Although it is recommended that users use only TAI or UTC, as their needs indicate, many major navigation system have used times offset from TAI by fixed amounts. The most important of these is GPS, which is offset by 19 seconds from TAI. A segment of the international timing community has proposed a revision of the definition of UTC to avoid the discontinuities due to intermittent leap seconds. A discussion of the motivations for a change and of possible solutions has been published by McCarthy and Klepczynski in the Innovations Section of the November, 1999 issue of GPS World. The authors consider the most significant reason for a change to be keeping spread-spectrum communication systems and satellite navigation systems compatible with each other and with civil times. Another reason is the emerging need in the financial community to keep all computer time-stamps synchronized. In order to survey the effects of any action, an URSI Commission J Working Group (WG) was formed, whose purpose was to prepare this report and propose further actions. Methodology A questionnaire (Appendix I) was distributed as widely as seemed appropriate (Appendix II). The goal of the questionnaire was to find and categorize those operations that would be adversely affected should a change in UTC's computation be made. The questionnaire focused on the possibility of simply inserting no new leap seconds, although alternative solutions were also solicited. Over 200 responses were received, and no effort was made to separate the responses of URSI members from those of nonmembers. The principal object of the questionnaire was to find what systems would be adversely affected should a change be made in leap second procedures rather than to convince users of the need for a change or to take a vote. However, so many queries on these matters were received that a "standard reply" (Appendix III) was developed and distributed as appropriate. In the spirit of full disclosure, the number of responses in each category is given, but we caution that this was by no means an unbiased sampling of all who would be affected by the change. All responses were counted only once, with preference to the most practical grounds for objection. About half the responses that were received were opposed to any change, while one-fourth were in favor of a change, and one-fourth indifferent. I. Responses Opposed to Changes in the Status Quo A. The expense of rewriting software. Five responses suggested that contractors would have to be hired to scrutinize and adapt large amounts of code for operational satellite systems. Efforts were made to contact these responders for specific dollar amounts, and one off-the-cuff estimate of "several $100,000" was received. The impact on such systems would be lessened if any decision to redefine UTC were announced several years in advance. Twenty-six others indicated that software would be a serious problem - a very few of these were from people who did not seem to understand the proposal. There were 9 responses involving telescope control; one of these, from the Keck Observatory, provided a rough estimate of a few programmer- months. Others pointed out the problems computing eclipses and occultations, for telescope pointing by amateurs, or with code they had themselves written for professional-level projects such as speckle interferometry. One observatory indicated its station clock can not accommodate a large UT1-UTC correction. Fourteen more indicated that software issues would be a problem, but that they are probably solvable. Some of these actually indicated support for the change. B. Inherent inability to rewrite software to allow for |UT1-UTC| exceeding .9 seconds. Ten responses involved navigational software. Taking the example of a software product of the US Naval Observatory (USNO), pilots and sailors are given the option to input UT1-UTC. However, it is expected that many users would not understand this and enter 0, leading to noticeable errors within a decade. These are similar to the telescope-control problems covered above, except that one could not and should not expect the general public to ever understand these issues. Problems amateur astronomers might have are also included here, and were brought up by many responders in other contexts. One of the problems anticipated is that UT1-UTC could be applied with the wrong sign, just as the leap second is occasionally applied with the wrong sign. An example of "buffer overflow" problem would happen in NIST's WWV, WWVH and WWWB transmissions, which do not allow enough space for |UT1-UTC| to exceed .9 sec. Any users of these broadcasts who might need this information and who are unaware of the problem, decoding in hardware, or relying on old software would be adversely affected. Under the best of future circumstances only the sub-second (tenths) digit would be available, requiring the user to keep track of the digits to the left of the decimal point. Not tabulated is an informal comment seriously made to the Working Group's Chairman, by a respected and competent scientist from a non-western nation, that astrologers would be adversely affected. C. Philosophical Objections Eight thought this would confuse or antagonize the public, religious authorities, or even scientists - in essence because solar time is "true time". (In contrast, one responder in favor of a change thought this would help educate the public to the fact that Earth rotation is not "true" time). Three pointed out that legal complications might occur in countries where laws are specified in terms of solar time, or GMT (which has not existed for thirty years). Although one of these responders feared governments would not follow the scientist's lead, we find it difficult to believe that governments would, on their own, choose to add leap seconds. Others thought that any legal system flexible enough to handle daylight savings time and the past abandonment of GMT in favor of UTC would easily accommodate a seamless change in UTC's computation, especially if no other time standard were available. Some of the history of legal issues concerning past changes in time definition can be found in the book "Greenwich Time and Longitude" by Derek Howse. Three thought we should not adopt a system which will fail in the long run, even if that is a very distant time in the future. (It could be pointed out that all current time systems will eventually fail. Well before 2050 we could be routinely adding more than one leap second per year, and when we reach the point where a day is 48 hours long we would have to add a leap second every second. Even the Gregorian calendar will eventually need revision because in a few million years the Earth will rotate less than 365 times per year, and leap days will not be necessary.) Two thought this would deprive the timing community of free publicity when leap seconds are inserted. Thirty-eight expressed opposition, but gave no specific reason. Eleven of those also indicated that a problem would exist with their system, but did not specify it. Some of these pointed out that TAI was readily available, or indicated that they had seen no justification for a change. (We had intentionally provided no justification in the initial questionnaire, but two responders replied that they still believed there was not enough reason to change even after having read "standard response".) Four were against it because they thought problems would happen if some systems did not use the new system, and because they thought one would have to separate analyses based upon whether data were recorded with the current system or the old system. (We believe these to be based upon a misunderstanding of the "no new leap seconds" proposal, but entirely possible if the more drastic measure of re-defining SI, the International Second, were adopted.) II. Alternative Suggestions Five suggested that it would be better to redefine the second to be longer, add 1 second every 18 months forever, change on leap years or century-ends, or change when the number exceeded a fixed amount. These possibilities are also discussed in the GPS World Article. A suggestion was received to add enough "negative leap seconds" to bring UTC in line with GPS. However, a different responder pointed out that many of NASA's programs assume UT1-UTC always grows and that problems would happen with any change that would sometimes lead to a "negative leap second". (According to Dennis McCarthy of the USNO, this is possible even with the current system, but unlikely). It was also pointed out that rubidium atomic fountains or optical standards could lead to a redefinition of the second using an element other than cesium. If so, it could be redefined using a scale factor of sufficient magnitude to avoid the short-term need for leap seconds (As noted in the GPS World article, such a change would alter the values of those physical quantities that depend upon time.) One suggested that a redefined UTC should have a new name. III. Responses in favor of changing the current leap second procedures Forty-eight responses in favor were received, several from people who experienced minor problems now in handling leap seconds, such as confusion due to GPS time being currently 13 seconds offset from UTC and computer errors at the time of the leap seconds. Along with responses based upon reasons already covered in the GPS World Article, there were also three from the highly undersampled group of computer programmers, which pointed out the growing need to synchronize diverse computers to one second accuracy and the difficulties of doing so in an when dates of future leap seconds were unpredictable. Many of the responses indicated that periodic addition of leap seconds on a scheduled basis would also be acceptable. One of the responders, who was opposed to a change, suggested that leap seconds were not a problem because computer users could program an automatic extraction of the needed information from some publicly available source; however it must be pointed out that no one can guarantee that a given file, whether it be for leap seconds or for daily values of UT1-UTC (see part IV, below), will remain forever available in a given format or given IP address. Four responses were from people who indicated that the convenience in not having to update files every 18 months outweighed the expense and problems rewriting software. One of these suggested the use of sufficient negative leap seconds to bring UTC in line with TAI, and several noted that UT1-users easily incorporate the offsets due to time zones and daylight time. IV. Other Responses Forty-seven responders checked the "indifferent" option. Most indicated that there would be no problems with their system, or that the problems were small enough that they were indifferent to a change. Seven other responders indicated that the change would be okay if they could somehow reliably obtain UT1-UTC. (The USNO, as a sub-bureau of the IERS, freely provides this information on its web site, http://www. maia.usno.navy.mil, and via weekly emailings. Other organizations also provide this information.) Some responses tabulated here were phrased in the negative because the responders were apparently unaware that the information was available. One responder was concerned that the GPS system itself would be degraded for this reason, however this is not the case because GPS currently uses UT1-UTC values derived from USNO products. ________________________________________________________________________ Appendix I. Questionnaire It is being proposed to change the definition of Coordinated Universal Time (UTC) regarding the insertion of leap seconds, possibly even eliminating their use. Leap seconds are introduced so as to keep UTC synchronized (within 0.9 s) to the time scale determined from the Earth's rotation. Should no new leap seconds be inserted, solar time will diverge from atomic time at the rate of about 2 seconds every 3 years, and after about a century |UT1-UTC| would exceed 1 minute. Although no fundamental problems are anticipated, it is very likely that Y2K-like problems may result in software that assumes UT1=UTC, or |UT1-UTC|< some value, or whose input/output records use a field size that can only accommodate |UT1-UTC| values up to one second. To gather information, an URSI Commission J Working Group was formed, consisting of Don Backer, Wim. N. Brouw, Barry Clark, Irwin Shapiro, Ir. E. Van Lil, with Demetrios Matsakis being the chair. We would like to ask you to consult with the members of your institute who currently deal with UT1-UTC, and give us a considered response to the following two questions: A. If the appropriate international bodies decide to eliminate the insertion of new leap seconds, would you foresee any practical problems for your institution/instrument/observations? no ____ * yes ___ * possibly ____ (* please explain any known or possible problems) B. Would you be in favor of such a proposal? yes ____ no ____ indifferent ___ have better idea ___ (feel free to comment) C. Is there anyone else you would recommend we contact? (feel free to forward this email directly) I would appreciate your assistance, and a response by January 15 to dnm(a)orion.usno.navy.mil. I am attaching a list of institutions and persons contacted, except for 931 institutions whose emails were obtained from the AAS. I would like to apologize to anyone contacted twice, but also appreciate it if you would forward this email to anyone we have missed. Also, if you are an URSI Commission J national chair, we would appreciate your forwarding this email to your complete membership and in particular to the directors of observatories. Sincerely, Demetrios Matsakis ________________________________________________________________________ Dr. Demetrios N. Matsakis Director, Time Service Department (202) 762-1587 DSN 762-1587 U. S. Naval Observatory FAX (202) 762-1511 3450 Massachusetts Avenue NW dnm(a)orion.usno.navy.mil Washington DC, USA 20392-5420 ________________________________________________________________________ Appendix II. Distribution List Efforts were made to conduct an international survey, and responses were received from Europe, Japan, China, Australia, Canada, Russia, Saudi Arabia, Brazil, and other countries. The majority of the responses, however, were from the U.S. Commercial interests, such as satellite companies, were highly undersampled. The questionnaire asked people to forward it to others, and we know the following were contacted: 1. 128 prominent scientists, who were mostly URSI Commission J members and official representatives of institutions associated with URSI. 2. 27 URSI Commission J national chairs. 3. 931 Institutions extracted from a database kept by the American Astronomical Society, including many from outside the United States. Several hundred of those email addresses proved invalid. 4. All on the USNO Series 7 mailing list. 5. All on the "Gazette" mailing list of the International Earth Rotation Service (IERS). This would be expected to include most scientific groups that are directly involved with UT1. 6. One responder who worked in SETI indicated he had forwarded it to SETI circles. 7. The Internet Engineering Task Force's mail exploder. 8. One responder, who was against any change, indicated he had forwarded the questionnaire extensively around Jet Propulsion Labs (JPL). ________________________________________________________________________ Appendix III. "Standard Reply" to queries concerning the questionnaire Thank you for your response, which will be tabulated. Unix-technology willing, we also plan to send a copy of our report all responders. Many people have asked me why there is a move to rethink the leap seconds, with solutions such as (but not limited to) adding no new leap seconds. I unfortunately edited out some of the reasons from early drafts of the questionnaire, because I was afraid that people would not read a long email. Since then, I have developed the following "standard reply": 1.) Many high-tech navigation systems, particularly those using spread-spectrum techniques, can't handle leap seconds very well. GLONASS, the Russian equivalent to GPS, goes off-line for leap second adjustments. Also, problems can occur in interfacing between systems that handle leap seconds differently. There is also the practical problem of inserting a second every year and half - people often do it the wrong way. The response one person sent me is below, and it concerns Network Time Protocol (NTP), which uses the internet to transfer time. > If leap seconds went away, the NTP community would worship the ground you > walk on. Leap secs introduce a manual discontinuity in the NTP time scale. > It takes a while to propagate leap secs through the hierarchy. Leap seconds > are a tremendous headache in the NTP world because they cannot be predicted. > One must set a flag to indicate that one is coming. I think it is a very > true statement that all GPS users would vote against continuing leap seconds, > not just NTP users. Many telecommunications circuits use GPS or atomic clocks > to keep cellular phones in operation, and leap seconds are a nuisance to them > as well. 2.) I also received many comments about the effects on society when UT1 diverges. Note that we are talking about a minute in the next century. Society routinely handles a one-hour switch with every daily savings time, and a half-hour offset if they live at the edge of a time zone. By the time leap seconds add up to an hour, the world will be very different. If we have settled the solar system, a whole new scheme will probably have evolved. Even if we have not changed our system, society has enough slop in its timekeeping that people will slowly shift without even knowing it. More people will start showing up to work at 9:00 AM, and less at 8:30 AM, etc. 3) The "Innovations" section in November's GPS World is on this subject, and discusses other possibilities aside from "no new leap seconds". These are inserting larger discontinuities less frequently, inserting integer leap seconds at predefined times, simply using TAI, and redefining the length of the second. 4) It should be pointed out that UT1-UTC is readily available on the web. The USNO, as a subbureau of the International Rotation Service, makes this information available via a weekly mailing and from a web page at http://www.maia.usno.navy.mil, and other organizations also provide this service. 5) My final comment is not to worry about any "surprise" decisions - before/if the international bodies all decide to do this, it will be fully debated and publicized. My role, here, is simply to gather information.

1 0

FW: Time zone info in Tasmania for year 2000
by Olson, Arthur David (NCI) July 3, 2000

July 3, 2000

Sim Alam is not on the time zone mailing list; direct replies appropriately. --ado > -----Original Message----- > From: Alam, Sim [SMTP:Sim.Alam@Central.tased.edu.au] > Sent: Monday, July 03, 2000 12:35 AM > To: 'tz(a)elsie.nci.nih.gov' > Subject: Time zone info in Tasmania for year 2000 > > Hi, > > Is the Time zone entry for the Year 2000 wrong in the Australasia time > zone > file version 7.46? The last sunday in August 2000 is the 27th and not the > 26th. Shouldn't the following be the right entries? > Rule AN 2000 only - Aug 27 2:00s 1:00 - > Rule AN 2001 max - Oct lastSun 2:00s 1:00 - > > Also, in the 7.46 version of the Australasia file Tasmania does not have > any > entries for 2000 (see > http://www.thelaw.tas.gov.au/fragview/42++1968+GS3A@EN+2000070300 for more > info) : > > Regards, > Sim Alam > > Information Management Branch > Department of Education > Level 2, 73 Murray Street > Hobart, Tasmania 7000 > Ph: +61 3 6233 6900 > Fax: +61 3 6233 6969

2 1

Long./lat. data
by Ralf Neubersch July 3, 2000

July 3, 2000

Does anybody know where I can get the timezones in longitude/latitude format to overlay them on generated maps? \Ralf

1 0

Time zone info in Tasmania for year 2000
by Alam, Sim July 3, 2000

July 3, 2000

Hi, Is the Time zone entry for the Year 2000 wrong in the Australasia time zone file version 7.46? The last sunday in August 2000 is the 27th and not the 26th. Shouldn't the following be the right entries? Rule AN 2000 only - Aug 27 2:00s 1:00 - Rule AN 2001 max - Oct lastSun 2:00s 1:00 - Also, in the 7.46 version of the Australasia file Tasmania does not have any entries for 2000 (see http://www.thelaw.tas.gov.au/fragview/42++1968+GS3A@EN+2000070300 for more info) : Regards, Sim Alam Information Management Branch Department of Education Level 2, 73 Murray Street Hobart, Tasmania 7000 Ph: +61 3 6233 6900 Fax: +61 3 6233 6969

1 0

Time Zone Editor
by Jesper Nørgaard July 1, 2000

July 1, 2000

The short version: Cut the below text to a text file and save it as tzsydney.reg. REGEDIT4 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Time Zones\Sydney] "Display"="(GMT+10:00) Melbourne, Sydney" "Dlt"="Sydney Daylight Time" "Std"="Sydney Standard Time" "TZI"=hex:a8,fd,ff,ff,00,00,00,00,c4,ff,ff,ff,00,00,03,00,00,00,05,00,03,00,00,\ 00,00,00,00,00,00,00,08,00,00,00,05,00,02,00,00,00,00,00,00,00 "MapID"="20,21" Now double click on tzsydney.reg which will load this to the registry. You should now be able to open Date/Time from Windows Settings and select "(GMT+10:00) Melbourne, Sydney" and click on the optionsbutton below so that Windows is handling daylight saving automatically. That is all there is to it! :-) First of all let me say I haven't tried it in Windows NT, only in Windows 95. According to documentation probably the key above would be [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Sydney] instead. Try it for yourself. I did use tzedit.exe to view the time zones in a Windows NT computer, and that worked fine. I did not try to update with it on the Windows NT computer. As mentioned in earlier mails Mickeysoft has made a program called Windows Time Zone Editor which handles these matters without having to fumble around with the registry editor poking in hexadecimal values. I have created a registry file with all known timezones that we know on the mailing list. If you are interested in this, please download the file http://timezone50.homepage.com/tzedit.zip which contains the following: tzedit.exe The Time Zone Editor tzedit.hlp Help file for the program tzedit.txt A text file I prepared with the information about which time zone in tznew.reg corresponds to which country. tznew.reg Registry file with all the timezones documented in tzedit.txt and the correct start and end times for year 2000. You can either import the full file into the registry, or copy-and-paste the time zone(s) you want first to another *.REG file, and then double click on that. These files can be used for any purpose you have, its "use-at-will-ware" :-) I have investigated this to include in my PC program Time Zone Converter (see also http://timezone50.homepage.com) but that hasn't been included yet. You might want to try the PC program though. Just to continue the discussion, I have noticed a problem at least in Windows 95. I don't know if it is also a problem in Windows 98 or Windows NT. I would be grateful if anybody knows or can investigate this on these machines. The problem: When using a time zone that has automatic daylight savings handled by Windows 95, then everything works fine if you turn off your computer every night before going to bed as any good Mickeysoftian :-) However, if you keep it on 24 hours a day, then there is a problem when leaving daylight saving. Lets say that at 3 o'clock in the morning Windows turn back the clock to 2 o'clock as it should. Then it was supposed to let time run ahead until 3 o'clock again, but now not turn the clock 1 hour back (since it reached 3 o'clock for the second time) but continue. Unfortunately it goes into an "endless" loop repeating to turn it back to 2 o'clock. The only way to leave this diabolic situation is to turn time ahead to after 3 o'clock, but at this point the registry has been screwed up. Any information about this will be of interest. Regards, Jesper Nørgaard Email: jnorgard(a)df1.telmex.net.mx Programador/Analista CIMMYT - Centro Internacional de Mejoramiento de Maíz y Trigo Dirección: CIMMYT, Lisboa 27, 06600 Mexico, D.F. Tel.: +52 (5) 7267541 ext. 1374 Fax: +52 (5) 7267558 Tel. Casa: 53-10-05-95 ó 53-10-97-78 CIMMYT home page: http://www.cimmyt.mx

1 0

TimesOwn - World Time Zone Clock
by Tom Hingston June 30, 2000

June 30, 2000

Hi I have been to your site and wondered if you would consider adding this software to your site. Timesown - World clock and time zone difference calculator A program to tell you what time it is now, in any time zone in the world. You add the countries or your friends names, enter the time difference (once), and you can keep it in your system tray, on the task bar, for easy reach. Great if you use chat programs like ICQ or Messenger, or if you do business with other countries. You will always know what the time is where your friends and contacts live. Features a.. Includes a 'Look up' that calculates most time differences for you. b.. 1 click daylight savings correction for you. c.. Simple installation and easy to use. d.. User choice - customise it to list cities or countries, or even your friends names. e.. List as many places as you want. f.. Auto refresh option - keeps times always up-to-date. g.. Open it as you want it, or leave it in the system tray (by the clock) for easy access. View it and download it from http://hingston.yi.org/chequers/timesown.html direct download http://hingston.yi.org/chequers/timesownzip.exe Shareware Windows95/98/NT/2000 Thanks for your consideration Tom Hingston cheq(a)xtra.co.nz

1 0

RE: FW: Romance Time (forwarded with permission)
by Dave Turnbull June 30, 2000

June 30, 2000

Hi re "makes me wonder whether that [Windows NT registry] could be edited instead." For Windows NT see the MS note Q176513 (in the MSDN Lbrary CDs or on the web at http://support.microsoft.com/support/kb/articles/Q176/5/13.ASP) for an example of ading a timezone to the list in Windows which can be selected from the Time/Date control panel applet. Although it doesn't talk about it in the article I expect you could then save that new subtree (as a .reg file) which can be "executed" on a(nother) user's computer. Dave Turnbull PS Apologies if I've broken etiquette by replying to the wrong names, I'm new on this mailing list. Point me to the FAQ! > -----Original Message----- > From: Alex LIVINGSTON [SMTP:alex@agsm.edu.au] > Sent: 30 June 2000 04:25 > To: Antoine Leca > Cc: tz(a)elsie.nci.nih.gov; Tim Stratford > Subject: Re: FW: Romance Time (forwarded with permission) > > At 18:49 +0200 2000-06-29, Antoine Leca wrote: > >> > From: Tim Stratford [SMTP:TStratford@oneworldsoftware.com] > >> > Sent: Thursday, June 29, 2000 10:44 AM > >> > To: 'ado(a)elsie.nci.nih.gov' > >> > Subject: One quick question please.... > >> > > >> > Dear Arthur David Olson, > >> > Today I was doing research concerning a time zone or aspect of > time > >> > called Romance Time. The research is for one of our software > customers > >> > and we cannot find much pertaining to the subject at all. Is their > some > >> > information which you could supply me about the subject or some > resources > >> > which I could further research? Thank you very much for your time > and > >> > cooperation. > > > >'Romance' is the name used for Europe/Paris and Europe/Madrid > >areas in the Windows time zone database. > > > > > >Hope it helps, > > > >Antoine > > I'm sure someone'll tell me if this is initiating a discussion that is not > relevant to the tz mailing list, but it involves keeping track of time on > computers... > > I'm not a Windows afficionado, and I doubt I'll ever be, but the > installation where I work now consists mostly of machines running one > version of Windows or another (at this stage mostly Windows NT 4). > > As southeastern Australia (where I am) is starting daylight saving > considerably earlier this year than hitherto, I was concerned to know how > all our Windows boxes (especially our servers) could be made to behave > civilly in this circumstance. I asked a colleage this week about whether a > suitable patch or update from Microsoft (for NT) was possible, but he said > only service packs, which require bringing down the machine, were issued. > The only way we could see of getting around the problem was by setting the > machines' time zone to "(GMT +11:00) Magadan, Solomon Is., New Caledonia" > until the date when NT thinks daylight saving starts in our zone ("... > Canberra, Sydney, Melbourne", from memory). Your (Antoine's) mention of > "the Windows time zone database" makes me wonder whether that could be > edited instead. > > I'd also be interested to know if anyone's worked out how to patch Mac > OS's > Date & Time control panel (presumably its 'cty#' resource) to effect the > same adjustment. > > Thanks for your attention. > > --Alex > > _______________ > Alex LIVINGSTON > Macintosh and Lotus Notes Support / Information Technology (IT) > Australian Graduate School of Management (AGSM) > UNSW SYDNEY NSW 2052 / Australia > > Facsimile: +61 2 9931-9349 / Telephone: +61 2 9931-9264 > Time : UTC+11---[last Mar. Sun.---UTC+10---[last Aug. Sun.---UTC+11--- > > At midday today, Friday, June 30, > time since epoch (1-1-1 at 00:00:00) is > 730300.5 days = 1999.49485616 average Gregorian years > time until 3rd millennium, 21st century, 201st decade, 2001st year is > 184.5 days = .50514384 average Gregorian years >

3 2