- tz - lists.iana.org

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

New ISO 3166 Maintenance Agency Web Site
by Markus Kuhn Nov. 27, 1999

Nov. 27, 1999

The ISO 3166/MA has now a web site with the official ISO 3166-1 country code list available online, as well as information about the ISO 3166-2 regional codes: http://www.din.de/gremien/nas/nabd/iso3166ma/ Latest addition 1999-10-01: PS = Occupied Palestinian Territory Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>

1 0

FW: zdump /zoneinfo question
by Olson, Arthur David (NCI) Nov. 22, 1999

Nov. 22, 1999

John Reynolds is not on the time zone mailing list; be sure to direct any replies to John. --ado -----Original Message----- From: Reynolds, John [SMTP:John.Reynolds@sciatl.com] Sent: Friday, November 19, 1999 4:16 PM To: 'tz(a)elsie.nci.nih.gov' Subject: zdump /zoneinfo question Hello, Please excuse the intrusion. I found this email address in some documents I downloaded from elsie.nci.nih.gov. I'm looking for some information or perhaps an online reference that can help me relate the output from the zdump utility to the changes for daylight savings for a particulat timezone. I've read the zic, zdump, ctime and localtime man pages. The zic manpage explains the format of the tz data files I found your name in. The output of zdump tells me when there is a change in the rules for a timezone but it doesn't seem to tell me what the rules are. In other words, given a particular zoneinfo file, how can I determine the zone and rules that were used to create it? My reason for asking is, how can I tell if the curent zoneinfo file is accurate given that governments can change the rules at any time. I've tried some experiments creating my own zoneinfo files then using zdump to display information about it but I see no way of determining the rules. Thanks for any help! John Reynolds john.reynolds(a)sciatl.com

3 2

zdump /zoneinfo question
by Reynolds, John Nov. 19, 1999

Nov. 19, 1999

Hello, Please excuse the intrusion. I found this email address in some documents I downloaded from elsie.nci.nih.gov. I'm looking for some information or perhaps an online reference that can help me relate the output from the zdump utility to the changes for daylight savings for a particulat timezone. I've read the zic, zdump, ctime and localtime man pages. The zic manpage explains the format of the tz data files I found your name in. The output of zdump tells me when there is a change in the rules for a timezone but it doesn't seem to tell me what the rules are. In other words, given a particular zoneinfo file, how can I determine the zone and rules that were used to create it? My reason for asking is, how can I tell if the curent zoneinfo file is accurate given that governments can change the rules at any time. I've tried some experiments creating my own zoneinfo files then using zdump to display information about it but I see no way of determining the rules. Thanks for any help! John Reynolds john.reynolds(a)sciatl.com

1 0

Proposal to eliminate leap seconds
by Eric Ulevik Nov. 16, 1999

Nov. 16, 1999

Probably off-topic, but anyway: ************************************************************************* Dear Project Manager or Scientist, 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, however many practical problems result from their implementation. 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? 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 eamil directly) I would appreciate your assistance, and a response by January 15 to dnm(a)orion.usno.navy.mil. [snip] 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 ________________________________________________________________________

1 0