- tz - lists.iana.org

FW: Time zone(s) in Mongolia
by Jesper Nørgaard Dec. 12, 1999

Dec. 12, 1999

fyi, this was sent to me by an "editor of someting" in Mongolia (sorry for not being more precise). Seems to me like pretty convincing refutation of several time zones in Mongolia. It should be added though that Mr. Lutaa is situated in Ulaanbaatar, not near Dund-Us. A confirmation from that region would seem appropriate. ---------- From: lut[SMTP:lut@magicnet.mn] Reply To: lut Sent: Domingo 12 de Diciembre de 1999 0.41 To: Jesper Nørgaard Subject: Re: Time zone(s) in Mongolia Dear Mr. Jesper Nørgaard, Thank you for your interest in Mongolia and our magazine. As for the time zoning, indeed Mongolia has time difference. When sun rises in Eastern provinces its still one hour late in Ulaanbaatar and everybody sleeps. While Kazakhs prepare for bed in Westernmost province of Byan Ulgii, the national television program still goes on. My colleagues in radio stations across the country have this problem. However, seemingly this does not pose a big problem as in China. And we adhere to only one time zone GMT +8.0. Yours, B.Lutaa ----- Original Message ----- From: Jesper Nørgaard <jnorgard(a)Prodigy.Net.mx> To: <lut(a)magicnet.mn> Sent: Sunday, December 12, 1999 1:17 PM Subject: Time zone(s) in Mongolia Hi. I just wondered if you know if Mongolia has several timezones, or just one (like China). In Ulaanbaatar you surely have GMT+8.0 e.g. the same as China, but I don't know if there are other time zones. What about Dund-Us, they have the same time as you? 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

Multiple time zones in Mongolia
by Paul Eggert Dec. 11, 1999

Dec. 11, 1999

Date: Sat, 11 Dec 1999 06:43:46 +0100 From: Oscar van Vlijmen <o.van.vlijmen(a)tip.nl> I think it is safe to assume that Mongolia has two time zones. Thanks for your information and references; I'll incorporate them into my next set of proposed changes. I'll CC: this message to the tz mailing list in case someone else can contribute info about Mongolia. Shanks writes that the Mongolian UTC+9 time zone didn't exist until 1983; perhaps it vanished some time between then and now. No one mentions DST. The IATA formerly agreed with Shanks that Mongolia observed DST, but the most recent issue of the SSIM (dated 1999-09) no longer says this. For lack of better information, I'll assume that Mongolia stopped observing DST starting this year. I think you should not use Dariv as the central place in the UTC+7 time zone. Take the more obvious Hovd. There are two Hovd in Mongolia, so you should add the alternative name Jargalant. Jargalant is problematic. Rand McNally spells it Jirgalanta. Shanks spells it Dzargalant (with a hacek over the z), or as Chovd. The CIA spells it something like Duno-Us; I can't quite read the scanned image in <http://www.lib.utexas.edu/Libs/PCL/Map_collection/middle_east_and_asia/Mong…>. We generally prefer the most populous location to represent a region, so we should use the most populous location in Hovd, Uvs, and Bayan-Olgiy. I suspect that the candidates are Jargalant (the capital of Hovd), Ulaangom (the capital of Uvs), and Olgiy (the capital of Bayan-Olgiy). Do you happen to know which is the most populous? Olgiy doesn't make it into Goode's, so I assume that it's smaller. If Ulaangom is larger than Jargalant, or if we can't figure out which is the larger, then I'd prefer to use Ulaangom, as its spelling is less problematic.

1 0

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