- tz - lists.iana.org

RE: International Date Line, international waters
by Law, Gwil Jr. Jan. 5, 2000

Jan. 5, 2000

Oscar van Vlijmen wrote: > [...] Gwillim Law noted: >>An Anglo-French Conference on Time-Keeping at Sea (June, 1917) agreed that >>legal time on the high seas would be zone time, i.e., the standard time at >>the nearest meridian that is a multiple of fifteen degrees. > [...] Theoretical timezones: > Take [0;15W), [15;30W),..., [165;180W), [180E;165E),..., [15E;0E) > Times in hours from UT. [ means including, ) means not including. > 0-15E +1 [...] Minor correction: what I was trying to express was that ships at sea should use UTC between 7.5 degrees E and 7.5 degrees W, UTC+1 between 7.5 degrees E and 22.5 degrees E, etc. Gwillim Law

1 0

For your amusement
by Manavendra Thakur Jan. 4, 2000

Jan. 4, 2000

Hi folks, I've been an observer ("lurker") of this mailing list for some years now. In my previous life, I used to use the information to provide free timezone patches for European customers of the operating system my previous company produced. My grateful and humble thanks to all of you who have contributed to the upkeep of this precious resource over the years! As a small token, here's something for your amusement that I saw in the New York Times newswire... I find it amazing that Cameron's Corner in Australia straddles three timezones. (But probably this isn't news to anyone on this mailing list!) Manavendra Thakur mthakur(a)alum.mit.edu December 29, 1999 'Auld Lang Syne' by 3 By THE ASSOCIATED PRESS SYDNEY, Australia, Dec. 28 -- Party, party, party! New Year's Eve celebrations at Cameron's Corner, a remote settlement in Australia's Outback, will be in triplicate, the local bar owner said today. The tiny village about 740 miles northwest of Sydney straddles three state boundaries, and three times zones. This means it will witness the end of the old and the start of the new millennium not once, not twice, but three times in the space of just one hour and one minute. Cameron's Corner's usual population -- four -- is expected to swell to around 1,000 on Dec. 31 as revelers head there for a millennium party with a difference. Copyright 1999 The New York Times Company

5 5

RE: International date line
by Law, Gwil Jr. Jan. 3, 2000

Jan. 3, 2000

John Cowan wrote: >> Niue, to take a simple example, is shown in my Rand McNally International >> Atlas surrounded by a rectangle extending from approximately 166.5 to 170.5 >> degrees West, and 17.5 to 23.5 degrees South. > > Okay. And this bounding box is defined by an international convention? > Or is it just RMcN's convention? I think it's an international convention. That's based on something I read several years ago. I don't have any reference for it at this date. As I tried to state, my original posting on this topic was more than mere speculation, but less than authoritative. Gwillim Law

2 1

RE: International date line
by Law, Gwil Jr. Jan. 3, 2000

Jan. 3, 2000

John Cowan wrote: >> The straight-line boundaries between Pacific >> island nations that are shown on many maps are based on an international >> convention, but are not legally binding national borders. > > I'm confused. Does this mean that there are overlapping claims to sovereignty, > or what? What is a "legally binding national border" anyway? As I understand the situation, sovereignty extends to the land area of each island, plus its territorial waters (the twelve-mile limit, or whatever the individual country claims). The "straight-line boundaries" I was talking about divide a large part of the Pacific into contiguous zones, extending well beyond the limits of sovereignty. Niue, to take a simple example, is shown in my Rand McNally International Atlas surrounded by a rectangle extending from approximately 166.5 to 170.5 degrees West, and 17.5 to 23.5 degrees South. The actual extent of Niue, including its territorial waters, can be contained within a rectangle from about 169.5 to 170.2 degrees West, and 18.7 to 19.4 degrees South. It would take me some time and effort to define "legally binding national border". I would define a "not-legally-binding-national-border" as a line on a map with no particular significance. Does that help? Gwillim Law

2 1

RE: International date line
by Law, Gwil Jr. Jan. 3, 2000

Jan. 3, 2000

> Does anybody know the exact geographical coordinates of the international > date line? The International Date Line is not defined by any international standard, convention, or treaty. Mapmakers are free to draw it as they please. Reputable mapmakers will simply ensure that every point of land appears on the correct side of the IDL, according to the date legally observed there. When Kiribati adopted a uniform date in 1995, thereby moving the Phoenix and Line Islands to the west side of the IDL (or, if you prefer, moving the IDL to the east side of the Phoenix and Line Islands), I suppose that most mapmakers redrew the IDL following the boundary of Kiribati. Even that line has a rather arbitrary nature. The straight-line boundaries between Pacific island nations that are shown on many maps are based on an international convention, but are not legally binding national borders. An Anglo-French Conference on Time-Keeping at Sea (June, 1917) agreed that legal time on the high seas would be zone time, i.e., the standard time at the nearest meridian that is a multiple of fifteen degrees. The date is governed by the IDL; therefore, even on the high seas, there may be some places as late as fourteen hours later than UTC. And, since the IDL is not an international standard, there are some places on the high seas where the correct date is ambiguous. This information is the best I could find when I was studying the question a few years ago. If any of the readers of this list have anything more authoritative, I would welcome corrections. Gwillim Law

2 1

International date line
by Oscar van Vlijmen Jan. 3, 2000

Jan. 3, 2000

Wishing every reader the very best for this millennium, I would like to ask: Does anybody know the exact geographical coordinates of the international date line? I have compiled from some of the better maps a very speculative list of coordinates and I hope that somebody is able to correct this list. 90N 180W (North pole) 75N 180W 68N 168W 66N 168W 53N 170E 47N 180W and now the Kiribati swing 2.5N 180W 0N 177W 0N 166.5W 3.3S 166.5W 3.3S 160W 2N 160W and now diagonally to, or first via 2N 162W? 5N 162W 5N 154.5W 2.3N 152.25W 7S 149W 12S 149W 12S 157W 7S 157W 7S 178.5W and following again the original line: 15.5S 172.25W 45S 172.25W 51S 180W 90S 180W (South pole) Regards, Oscar van Vlijmen 2000-01-01

2 1

Re: Could anyone help, corrected URL
by Oscar van Vlijmen Dec. 29, 1999

Dec. 29, 1999

To: "Dave's DHL Mail" <dkelly(a)lhr-sys.dhl.com> And copy to: tz(a)elsie.nci.nih.gov Dave wrote: >I'd like to produce a list of all the distict beginnings of the new >millenium - listing the zone and UTC time when they will first see the new >millenium, e.g.: > >Pacific/Chatham Island Dec 31 10:15 UTC >.... >Europe/Paris Dec 31 23:00 UTC >Europe/London Jan 1 00:00 UTC >... >etc.. > >Dave Kelly Hi! I have recently made a Macintosh HyperCard application, based upon the TZ database information. Can be found on my site. Furthermore, I have made a small list with the first zones and the last zones that will greet the new millennium. This list can be found at: http://www.tip.nl/users/o.van.vlijmen/firstlatestzones.html Without any notice my service provider changed something in the naming of URL's, resulting in an error if you try to follow the given URL. My page still exists, use the 'direct' address: http://www1.tip.nl/~t876506/firstlatestzones.html Regards, Oscar van Vlijmen 29-12-1999

1 0

Could anyone help
by Dave's DHL Mail Dec. 29, 1999

Dec. 29, 1999

Hello Everyone, First, thanks to all on the list for the useful (and often amusing) information that's been passed round for the last couple of years. Next, I wonder if anyone can help with a little light hearted excercise - I'm afraid my coding isn't up to it and I don't have access to a compiler at home anyway... I'd like to produce a list of all the distict beginnings of the new millenium - listing the zone and UTC time when they will first see the new millenium, e.g.: Pacific/Chatham Island Dec 31 10:15 UTC .... Europe/Paris Dec 31 23:00 UTC Europe/London Jan 1 00:00 UTC ... etc.. I'd be really grateful if anyone can help with this, or alternatively point me to a list that already exists on the web somewhere. Thanks again, and best wishes for *your* new Millennium Dave Kelly

2 1

Re: Could anyone help
by Bradley White Dec. 29, 1999

Dec. 29, 1999

> I'd like to produce a list of all the distict beginnings of the new > millenium - listing the zone and UTC time when they will first see the new > millenium, e.g.: > > Pacific/Chatham Island Dec 31 10:15 UTC > .... > Europe/Paris Dec 31 23:00 UTC > Europe/London Jan 1 00:00 UTC > ... > etc.. > > I'd be really grateful if anyone can help with this, or alternatively point > me to a list that already exists on the web somewhere. #!/usr/bin/env perl use integer; use strict; use POSIX qw(mktime strftime tzset); # set $tzdir and $bogon as you see fit my $tzdir = '/usr/share/zoneinfo'; my $bogon = '^(right|posix|Etc|SystemV)/|\.tab$' .'|^(Factory|UTC|localtime)$|^GMT.' .'|^(..T|.ST\d.DT)$'; my %mill = (); chdir $tzdir or die "$tzdir: $!\n"; foreach my $zone (`find * -type f -print`) { chomp $zone; next if $zone =~ m:$bogon:o; $ENV{'TZ'} = $zone; tzset; my $when = mktime(0, 0, 0, 1, 0, 2000-1900); $mill{$when} = [] unless exists $mill{$when}; push @{$mill{$when}}, $zone; } foreach my $when (sort { $a <=> $b } keys %mill) { my %zones = (); foreach my $zone (@{$mill{$when}}) { my ($dev, $ino) = stat $zone; next unless defined $ino; $zones{"$dev.$ino"} = [] unless exists $zones{"$dev.$ino"}; push @{$zones{"$dev.$ino"}}, $zone; } print strftime "%b %d %H:%M UTC\n", gmtime $when; foreach my $devino (keys %zones) { print ' 'x4, join('|', sort @{$zones{$devino}}), "\n"; } } exit 0;

2 1

Re: Could anyone help
by Bradley White Dec. 29, 1999

Dec. 29, 1999

Oops ... I forgot to account for daylight savings in the call to mktime. Sorry about that. #!/usr/bin/env perl use integer; use strict; use POSIX qw(mktime strftime tzset); # set $tzdir and $bogon as you see fit my $tzdir = '/usr/share/zoneinfo'; my $bogon = '^(right|posix|Etc|SystemV)/|\.tab$' .'|^(Factory|UTC|localtime|posixrules)$' .'|^GMT.|^(..T|.ST\d.DT)$'; my %mill = (); chdir $tzdir or die "$tzdir: $!\n"; foreach my $zone (`find * -type f -print`) { chomp $zone; next if $zone =~ m:$bogon:o; $ENV{'TZ'} = $zone; tzset; my $when = mktime(0, 0, 0, 1, 0, 2000-1900, 0, 0, -1); $mill{$when} = [] unless exists $mill{$when}; push @{$mill{$when}}, $zone; } foreach my $when (sort { $a <=> $b } keys %mill) { my %zones = (); foreach my $zone (@{$mill{$when}}) { my ($dev, $ino) = stat $zone; next unless defined $ino; $zones{"$dev.$ino"} = [] unless exists $zones{"$dev.$ino"}; push @{$zones{"$dev.$ino"}}, $zone; } print strftime "%b %d %H:%M UTC\n", gmtime $when; foreach my $devino (keys %zones) { print ' 'x4, join('|', sort @{$zones{$devino}}), "\n"; } } exit 0;

1 0

other Nunavut hamlets rebel and stay on Eastern time
by Paul Eggert Dec. 28, 1999

Dec. 28, 1999

We already knew about Pangnirtung, but Michaela Rodrigue, writing in the Nunatsiaq News (1999-11-19), reports: The Baffin communities of Clyde River, Pangnirtung and Sanikiluaq now operate with two time zones, central - or Nunavut time - for government offices, and eastern time for municipal offices and schools.... Igloolik [was similar but then] made the switch to central time on Saturday, Nov. 6 ... after Nunavut Premier Paul Okalik reassured them the unified time zone would be reviewed in one year. Reference: http://www.nunatsiaq.com/archives/nunavut991130/nvt91119_17.html

1 0

data on DST changes all over the world
by Geelen, Paul Dec. 22, 1999

Dec. 22, 1999

Hi Elsie, How surprised I was to find this site.(http://sandbox.xerox.com/stewart/tzconvert.cgi). Since I am corresponding a lot with colleagues in different places all over the world, I would like to gain information on daylight saving changes that will occur in the next year. Could you please give me any data on these DST changes, for example in a spreadsheet or ascii file with the information as given below? country Netherlands timezone GMT + 1 from 1999, march 28, 02:00 AM until 1999, october 3, 02:00 AM shift + 1 hour country Brasil (east) timezone GMT - 3 from 1999, october 3, 02:00 AM until 2000, february 20, 02:00 AM shift + 1 hour I would be very pleased to hear from you. Thanks in advance. > Paul > __________________________________ > > room: VN 5.28 040 - 27 87 903 > E-mail: Paul.Geelen(a)nl.origin-it.com > __________________________________ > > >

1 0

RE: Multiple time zones in Mongolia
by Law, Gwil Jr. Dec. 13, 1999

Dec. 13, 1999

> 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 have Dund-Us as the capital of Hovd province, with Hovd and Jirgalanta as older names which may still be in use for this city. Still older names include Khobdo and Kobdo. > 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? Looking in a 1980 Hammond atlas that I have at hand, I find the following populations for cities in the three provinces in question. They're out-of-date, but they may indicate relative sizes. Bulgan, Hovd 3,100 Dund-Us, Hovd 12,400 * Hyargas, Uvs 1,600 Olgiy, Bayan-Olgiy 11,700 * Tsagaannuur, Bayan-Olgiy 2,000 Tsetseg, Hovd 700 Ulaangom, Uvs 14,000 * It looks as if the three provincial capitals (*) are the only good candidates. Since ambiguity is a criterion for rejecting a location name, I checked the NIMA place names website. It has 6,161 records of populated place names in Mongolia, including variants. The NIMA database agrees with me about the preferred names of the three provincial capitals, as listed above. In the NIMA database, the names Dund-Us and Ulaangom are both unique. Among the other proposed names, Jargalant is the least desirable: there are 13 cities whose preferred names are Jargalant. There are three places whose preferred names are Hovd. There are two places named Olgiy, but one of them is a variant name for Har-Us. Darvi, not Dariv, is shown as a variant for Bulgan. There is a city named Dariv, but it's not in the new time zone. Doing some more research, I found the home page of the Mongolian National Statistical Office, at <http://statis.pmis.gov.mn/home_engl.htm>. There, I found the populations of the three capitals according to the 1989 census and an estimate for year-end 1998. 1989 1998 Dund-Us 24,100 27,400 Olgiy 27,200 21,000 Ulaangom 22,900 26,500 Following the published criteria, Dund-Us is the top choice, with Ulaangom a close second. Dund-Us is more centrally located in the zone, which might give it more of an edge. Yours, Gwillim Law

2 1

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

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