December 1999 - tz - lists.iana.org

UTC Questionnaire response
by Joseph S. Myers Dec. 11, 1999

Dec. 11, 1999

This is a personal response to the UTC Questionnaire, as an individual contributor to the public domain UNIX timezone database at elsie.nci.nih.gov. I had originally not intended to respond to this questionnaire, since my experience is in the study of historical timezone changes and summer-time rules, and my views on the technical issues considered on their own are generally in accordance with those expressed in the response by Markus Kuhn, but on further consideration I decided that historical timezone research shows up potential practical, civil and legal issues that could arise with the decoupling of UTC from UT1, and of which it might be desirable to present a summary. In general, the time used for everyday purposes in most parts of the developed world (where time signals are readily available) is based on UTC, as distributed by time signals, with an offset that is normally an integral number of hours depending on the local timezone and summer-time arrangements. However, the legal definition of the time to be used may vary from country to country; for example, in the United Kingdom the time has been based on Greenwich Mean Time since 1880 (except that the whole of Ireland used Dublin Mean Time until 1916, then a single period of summer time at DMT plus one hour, then time based on Greenwich); while it has been proposed to change to a UTC-based definition, this sort of matter has not been a legislative priority. Although GMT has been replaced as a designation of a timescale by more precise definitions of variants of UT, it seems most likely that GMT would be taken, if UTC were decoupled from UT1, to be UT1 or very close to it, rather than UTC. In France, the time is now based on UTC, but from 1911 until 1978 the definition was based on Paris Mean Time, retarded by 9 minutes 21 seconds. The European Union directives defining the start and end points of summer time in the EU still state the relevant points in terms of Greenwich Mean Time. The time used in Liberia did not change to a Greenwich-based zone until 1972. >From this, it seems likely that many countries have definitions of legal time based on GMT rather than UTC; and, while the difference is insignificant for the purposes of everyday life, changing it has been of no great priority; a second here or there is not generally of great significance in the timing of everyday events. However, if UTC and UT1 are decoupled, it would seem likely that the legal and practical times would for the most part be allowed to drift, at least until this caused notable problems and quite likely for some time thereafter. Examples of the problems arising, taken from the 1847-1880 period when legal time in Great Britain was local time but for most purposes Greenwich time, as used by the railways, was used, may be found in Howse's book (Greenwich Time and the Longitude). In 1858 the case of Curtis v. March (where a court wrongly disposed of a case because the defendant had not appeared on time by the court clock, on Greenwich Time, but appeared on time by local time) lead to the case law that legal time was local time (though almost all clocks showed Greenwich time). Despite the confusion so caused, and the lack of ready availability of local time, the matter was not legislated upon until 1880. It seems plausible that similar disputes, about whether or not something was done within specified times, could arise if UTC and UT1 were substantially decoupled. While it would be clearly desirable for legislation in all countries to establish the legal time as being based on the readily available time scale, UTC, rather than GMT, I do not expect this state to be approached for several decades if it becomes practically important, or much longer if it does not. > 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? I would expect the problems described above to arise somewhere for some people, to cause confusion in areas where exact timing is legally important, and so to provide a source of undeserved extra income to lawyers. I would not expect to be involved in any such problems myself. It would be appropriate to study what legal definitions of time scales are used around the world, and whether eliminating leap seconds would cause any change in such definitions. > B. Would you be in favor of such a proposal? My preference would be for Markus Kuhn's proposal of leap seconds announced several decades in advance. -- Joseph S. Myers jsm28(a)cam.ac.uk

1 0

FW: partial Macintosh port
by Olson, Arthur David (NCI) Dec. 10, 1999

Dec. 10, 1999

Oscar is not on the time zone mailing list; be sure to direct any replies appropriately. --ado -----Original Message----- From: Oscar van Vlijmen [SMTP:o.van.vlijmen@tip.nl] Sent: Thursday, December 09, 1999 9:53 PM To: tz(a)elsie.nci.nih.gov Subject: partial Macintosh port Dear reader, Partial Macintosh port ---------------- Your excellent timezones information is sadly not available to Macintosh users, apart from the difficult to read text files. Therefore I have made a HyperCard application, based upon the current, so not the historical, timezone information in the tzdata directory. I intend to keep my HyperCard application up to date. It can be found on my site: http://www.tip.nl/users/o.van.vlijmen/AboutTimeZonesHC.html and it has been submitted to Info-Mac. This application is freeware and can be freely distributed, but not to be used for commercial applications and not on CD-ROM's. >From the Read Me ------------- This HyperCard stack by Oscar van Vlijmen can show the time in ALL known time zones, taking the daylight savings time (summertime) into account. Enter a time, set a few time zones, and this stack will compute the correct time in the set time zones. From base time to zone time and vice versa. If you enter a date as well, the correct daylight savings time corrections (summertime) are taken into account. This version can show up to 12 timezones at once. Additions, corrections ---------------- Compared to your database I have made a separate card (record) for each and every timezone, including the uninhabited islands. I have looked up all geographical coordinates, more or less missing from your database. Furthermore I have found a few small errors. For instance, the Brazilian island (Southamerica file) is called Trindade, not Trinidade. I think it should be Manahiki island (Australasia file), part of Cook Islands, not Manihiki. However, the Millennium Edition of the Times atlas says Manihiki Atoll. And also part of the Cook Islands: Rakahanga Atoll is more often used than your Rakehanga. The Times atlas says Rakahanga. For the moment I follow your ONE Mongolian time zone. I did some investigations, however not in Mongolia itself, which give the impression that Mongolia has two timezones. It looks as if the Mongolians themselves don't know, because some Mongolian Internet sites tell you there is one zone, others say two. Lonely Planet says two. If you like, I could send you more details of my investigations. If someone is interested, I could compile and send you a list of all geographical coordinates in my application, including the ones I have found. Regards, Oscar van Vlijmen 10-Dec-1999

2 1

partial Macintosh port
by Oscar van Vlijmen Dec. 10, 1999

Dec. 10, 1999

Dear reader, Partial Macintosh port ---------------- Your excellent timezones information is sadly not available to Macintosh users, apart from the difficult to read text files. Therefore I have made a HyperCard application, based upon the current, so not the historical, timezone information in the tzdata directory. I intend to keep my HyperCard application up to date. It can be found on my site: http://www.tip.nl/users/o.van.vlijmen/AboutTimeZonesHC.html and it has been submitted to Info-Mac. This application is freeware and can be freely distributed, but not to be used for commercial applications and not on CD-ROM's. >From the Read Me ------------- This HyperCard stack by Oscar van Vlijmen can show the time in ALL known time zones, taking the daylight savings time (summertime) into account. Enter a time, set a few time zones, and this stack will compute the correct time in the set time zones. From base time to zone time and vice versa. If you enter a date as well, the correct daylight savings time corrections (summertime) are taken into account. This version can show up to 12 timezones at once. Additions, corrections ---------------- Compared to your database I have made a separate card (record) for each and every timezone, including the uninhabited islands. I have looked up all geographical coordinates, more or less missing from your database. Furthermore I have found a few small errors. For instance, the Brazilian island (Southamerica file) is called Trindade, not Trinidade. I think it should be Manahiki island (Australasia file), part of Cook Islands, not Manihiki. However, the Millennium Edition of the Times atlas says Manihiki Atoll. And also part of the Cook Islands: Rakahanga Atoll is more often used than your Rakehanga. The Times atlas says Rakahanga. For the moment I follow your ONE Mongolian time zone. I did some investigations, however not in Mongolia itself, which give the impression that Mongolia has two timezones. It looks as if the Mongolians themselves don't know, because some Mongolian Internet sites tell you there is one zone, others say two. Lonely Planet says two. If you like, I could send you more details of my investigations. If someone is interested, I could compile and send you a list of all geographical coordinates in my application, including the ones I have found. Regards, Oscar van Vlijmen 10-Dec-1999

1 0

FW: Possible error in Tonga time zone (forwarded with permission)
by Olson, Arthur David (NCI) Dec. 7, 1999

Dec. 7, 1999

Jesper is not on the time zone mailing list; be sure that any replies are directed appropriately. --ado -----Original Message----- From: Jesper Nørgaard [SMTP:jnorgard@Prodigy.Net.mx] Sent: Saturday, December 04, 1999 4:38 AM To: Olson, Arthur David (NCI) Subject: Possible error in Tonga time zone Hi, Arthur David Olson. I understand that you have done a lot of work on time zone rules to be used in programs, and I have been using the files in elsie.nci.nih.gov for my own PC program which you can download from http://www.cimmyt.cgiar.org/timezone/timezone.exe, which is an installation executable of 505 Kb. The program only works in 32-bit Windows, meaning Windows 95, Windows 98 and Windows NT 4.0 and upwards. The installation program can guide you through the process. The program is free to copy and use, by the way. I have noticed a change in Tonga which on http://www.timezoneconverter.com/tzchist.html is referred to as: "Tonga now observes DST from the first Saturday in October until the Third Saturday in April.(Tonga will now be the first country to observe the year 2000.) " However, in the australasia file I find the following current rule for Tonga: # Tonga # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Tonga 1999 max - Oct Sat>=1 2:00s 1:00 S Rule Tonga 2000 max - Apr Sun>=16 2:00s - - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Pacific/Tongatapu 12:19:20 - LMT 1901 12:20 - TOT 1941 # Tonga Time 13:00 - TOT 1999 13:00 Tonga TO%sT In this case there is a discrepancy, since the third Sunday of April could fall on 15.th. of April, meaning that in that single case (which first happens 15.th. of April 2001) Tonga will leave Daylight Saving at Sunday the 22.nd. of April 2001 according to the above rule, but at Sunday the 15.th. of April 2001 according to the web page informal rule. My guess is that the rule really should state "Sun>=15" instead of "Sun>=16". Note that both rules will work correctly the year 2000, the problem arises first in 2001. Who is right? Hope you have a chance to look at my Time Zone Converter program by the way, and tell me what you think. A notabene is that I by mistake put my rule for Tonga leaving Daylight Saving as Last Saturday of April instead of Last Sunday. I will correct that as quickly as time permits ... Yours sincerely Jesper Nørgaard Welen, 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

2 1

Re: TAI via GPS
by Markus Kuhn Dec. 7, 1999

Dec. 7, 1999

"Joseph S. Myers" wrote on 1999-12-04 12:14 UTC: > Do you happen to know what GPS receivers are available that provide user > access to TAI (or some other form of the leap second offset information > transmitted in GPS; ideally all the parameters from Table 2-11 (UTC > Parameters) of the GPS Standard Positioning Service Signal Specification > 2nd Edition)? This doesn't seem to be the sort of feature manufacturers > of GPS receivers advertise, but it's of more interest to me in a GPS > receiver than the route storage features that get promoted. I don't have much experience with current low-cost GPS receivers and their serial port protocols. When we played in Erlangen around with NTP, we had a Mainberg GPS167 time receiver, i.e. a GPS receiver that was especially designed for reference clock applications. And even that one did *not* provide TAI, or the current UTC-TAI or UTC-GPS difference. It's output format looked suspiciously compatible to that of other Meinberg DCF77 receivers, which naturally have no clue about TAI. More info on Meinberg receivers is available on http://www.meinberg.de/english/index.htm including the full manuals. Also the IRIG-A and IRIG-B US military standard time telegram formats supported by some GPS reference clock receivers only provide UTC and do not allow you to reconstruct TAI. I have seen output from some Trimble GPS receivers that contained the GPS time as a (week, second) pair, which can be converted easily into TAI, but I am also not sure, how much of the leap second announcement you can access here. Trimble clocks such as the Thunderbolt on http://www.trimble.com/oem/om_timng.htm support the Trimble Standard Interface Protocol (TSIP) via RS232 as documented on http://www.trimble.com/support/files/thunder.htm Even there, they don't mention whether TAI is available. A bit more information is available on ftp://ftp.trimble.com/pub/tracking/pla400-TAIP-Reference.pdf which describes the Trimble ASCI Interface Protocol (TSIP). It *does* provide in the TM message a 2-digit "GPS/UTC Time Offset" field that indicates the number of seconds, but there is no leap second announcement field. Conclusions: If you look long enough, you might get TAI extracted out of a good GPS receiver, but not all GPS receivers support this and even for those that do, the leap second announcement is not necessarily available or well supported, or the documentation is very obscure. No wonder, hardly anybody is using TAI in practice and everything is UTC based. Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>

3 2

Re: UTC questionnaire
by D. J. Bernstein Dec. 5, 1999

Dec. 5, 1999

Paul Eggert writes: > But POSIX specifies UTC, No. UTC includes leap seconds; the POSIX scale does not. The POSIX scale includes a leap day in the year 2100; UTC does not. UTC is a safe format for timestamps, even in the most demanding scientific applications; the POSIX scale cannot be used for accurate timestamps during a leap second. ---Dan

2 1

Re: UTC questionnaire
by D. J. Bernstein Dec. 5, 1999

Dec. 5, 1999

Markus Kuhn writes: > The bulk of UNIX software also uses a fixed formula to break the time_t > value down to a decomposed yyyy-mm-dd hh:mm:ss time. That ``formula'' is isolated in a few lines of code that are invoked by the rest of the system. New calendar rules, new time-zone systems, etc. don't require changes except in those few lines of code. In contrast, there are thousands of lines of code that add or subtract time counters to handle real-time differences. This code wouldn't work correctly if the UNIX kernel were modified to follow the POSIX rules. You claim that nobody would notice, but I've seen several complaints about wobbly clock behavior from people who use xntpd to reset their time counters after leap seconds. The bottom line is that I'm running several UNIX systems that provide accurate civil-time displays and accurate real-time differences; I only had to fix a small amount of code. Your systems, on the other hand, have inaccurate civil-time displays and inaccurate time differences; your unimplemented ``solutions'' would require massive code changes. ---Dan

2 1

Re: UTC questionnaire
by D. J. Bernstein Dec. 4, 1999

Dec. 4, 1999

1. Do I correctly understand that, under this proposal, IERS expects the civil authorities to change the local time zone every few thousand years so that the sun is roughly overhead at 12:00? (Assuming, of course, that the world keeps using local time long enough for this to be an issue.) 2. To correct some information you've received about UNIX: UNIX does not keep track of time in UTC. UNIX keeps track of time as an integer (plus, in some cases, a 6-digit or 9-digit fractional part) that counts seconds. The bulk of UNIX time-handling software simply adds or subtracts these integers to schedule or measure real-time events. The popular Olson tz library in ``right'' mode interprets the counter as the number of TAI seconds since 1970-01-01 00:00:10 TAI, and converts it to local time for human display, taking account of leap seconds. It can also convert from local time back to the counter. Many applications call this library. Unfortunately, previous time libraries didn't understand leap seconds--- UNIX predates leap seconds!---and this mistake was codified in the POSIX standard, along with an incorrect leap-year rule. There are still some programs that produce silly results during leap seconds. But they'll be fixed eventually. 3. The tz library won't work past 2038. I've been writing a new library intended to work until the Gregorian calendar is replaced. This code will, of course, be easier to write correctly if there are no more leap seconds. ---Dan

3 2

change to tz list
by Bradley White Dec. 3, 1999

Dec. 3, 1999

Hello ado, Could you please change <bww(a)fore.com> to <bww(a)laurelnetworks.com> in your tz distribution list. thanks, Bradley

1 0

[Poul-Henning Kamp: UTC questionnaire]
by Garrett Wollman Dec. 3, 1999

Dec. 3, 1999

For your edification.... (Forwarded by permission.) -GAWollman ------- start of forwarded message (RFC 934 encapsulation) ------- Message-ID: <2538.944162601(a)critter.freebsd.dk> From: Poul-Henning Kamp <phk(a)critter.freebsd.dk> To: dnm(a)orion.usno.navy.mil Cc: core(a)freebsd.org Subject: UTC questionnaire Date: Thu, 02 Dec 1999 20:23:21 +0100 Dear Mr. Matsakis, I am answering your questionaier on behalf of The FreeBSD project, a supplier of a UNIX family Computer Operating System: >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 ____ In fact it would eliminate a few minor inconveniences every time it happens: UNIX computers account for time using the UTC scale with an epoch of 00:00 01/01/1970 UTC, so the computer needs its clock adjusted for a leap-second. Online transactions is a phenomena in sharp increase and the issue of keeping and legally documenting "time of transaction" in the face of leap-seconds is certainly too expensive for the benefit we see from them. UNIX is also a widely used operating system for science and research and the fact that no widely available facilities exist for calculating actual time difference between two events on either side of a leap-second is known to have bitten more than one scientific author over the years. Obviously it would be simple to provide these facilities, but the fact that operating systems are seldomly upgraded would relatively soon render the list of leap-seconds obsolete and the facility thereby useless. >B. Would you be in favor of such a proposal? > > yes ____ > Absolutely. If it is deemed desirable to keep UTC and UT1 synchronized it would be of tremendous benefit if the leap-seconds could be predicted or even just declared earlier than in the current mode of operation. A rule along the lines of "a leapsecond every 18 months" would go a long way to keep UTC and UT1 tied closely while at the same time providing a predictability for "normal civilization" equivalent to what we know from leap-days. Alternatively, rather than abandon leap-seconds make it leap-minutes. Once in a century we could probably use an extra minute anyway. Poul-Henning Kamp phk(a)FreeBSD.org In message <199912021444.PAA09602(a)hpopa.obspm.fr>, iers(a)hpopa.obspm.fr writes: > >*************************************************************************** > Gazette IERS Gazette IERS Gazette IERS Gazette IERS Gazette > ________________________________________ > No 48, 02 December 1999 / >_________________________________/ Contact: iers(a)obspm.fr > ftp: hpiers.obspm.fr (145.238.100.28) > WWW: http://hpiers.obspm.fr >*************************************************************************** > > Subject: UTC Questionnaire > Author : Demetrios Matsakis > >-------------------------------------------------------------------------- > > >Dear Colleague, > >It has been 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, and myself. > >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? > > yes ___ > > * no ____ > > * 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 eamil 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 >_____________________________________________________________________ > - -- Poul-Henning Kamp FreeBSD coreteam member phk(a)FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! ------- end -------

2 1