From hellosticky at gmail.com Sun Jul 1 14:26:27 2007 From: hellosticky at gmail.com (Kevin) Date: Sun, 1 Jul 2007 10:26:27 -0400 Subject: FW: Implementation of zoneinfo (Olson, tz) database in .NET c-sharp csharp In-Reply-To: <87bqf9tdlu.fsf@penguin.cs.ucla.edu> References: <87bqf9tdlu.fsf@penguin.cs.ucla.edu> Message-ID: <6936856c0707010726k7c48f255t3f7c499de89222ca@mail.gmail.com> Hi tzlist, I created this PublicDomain package as well as the tz database integration. I had been meaning to notify the list, but the current support is quite experimental, so I was waiting until I could make it more robust to get public comments... Alas, I got caught up in creating a start-up (of which this PublicDomain set of classes is an off-shoot). I guess the cat's out of the bag :-) That's okay, and if anyone is interested in contributing, that would be greatly appreciated. A response to the questions is below.... On 6/21/07, Paul Eggert wrote: > "Olson, Arthur David (NIH/NCI) [E]" writes: > > > From: Joshua Kifer [mailto:joshua at jotts.com] > > Sent: Wednesday, June 20, 2007 8:33 PM > > > > http://www.codeplex.com/publicdomain > > Thanks for mentioning that. Do you know how it works? It appears to > have a copy of the tz database, translated into C# (how?). There is a class called TzDatabase which parses the tz database into logical constructs, then emits C# code, which is manually placed into the static initializer, and the whole package is recompiled. This adds a few seconds to each static initialization of the class, which is the trade off for not performing File I/O on DLL resources or the filesystem (mostly for security permission reasons). > > Suppose a new version of the tz database comes out: how would the > change be propagated? > A new version of PublicDomain would have to be created and this new DLL would be re-downloaded and installed (no automatic way of doing this). I am *very* open to criticisms. If there is a better way to implement tz database support, I would be interested; however, one of the main design goals was to require very little from the "integrator" (i.e. the consumer of PublicDomain and TzTimeZone/TzDateTime). Therefore, using resource files which must be loaded from the DLL or file system would require FileIOPermission, and I felt that a larger load time (due to static initialization) and the tz database compiled in was the better choice. I am open to changing this. By the way, if you install PublicDomain.msi, all code is placed into C:\Program Files\PublicDomain\ (it is not yet tested on Linux), including TzDatabase.cs, TzDateTime.cs, and TzTimeZone.cs. Thanks, Kevin Grigorenko From hellosticky at gmail.com Sun Jul 1 14:37:53 2007 From: hellosticky at gmail.com (Kevin) Date: Sun, 1 Jul 2007 10:37:53 -0400 Subject: FW: Implementation of zoneinfo (Olson, tz) database in .NET c-sharp csharp In-Reply-To: <6936856c0707010726k7c48f255t3f7c499de89222ca@mail.gmail.com> References: <87bqf9tdlu.fsf@penguin.cs.ucla.edu> <6936856c0707010726k7c48f255t3f7c499de89222ca@mail.gmail.com> Message-ID: <6936856c0707010737m50b4b270te6d4c37ec6a35017@mail.gmail.com> "Joshua Kifer" writes: >> the only thing being retained is the timezone name and its UTC >> offset. No historical data is utilized. > > Thanks. Here's a draft of what could go into tz-link.htm; comments > and corrections are welcome. > >
  • PublicDomain > has a copy of a recent tz database, accessed via a href="http://en.wikipedia.org/wiki/C_Sharp">C# library. As its > name suggests, it is in the public domain. Only current time stamps > are supported; historical data are not used.
    • By the way, the historical data exists, I just haven't implemented accessor methods to retrieve that data. This data is already compiled in to the runtime binary. However, it can be retrieved manually through the TzDatabase class, although that requires a local copy of the tz database. Thanks, Kevin From emuller at adobe.com Sun Jul 1 17:07:11 2007 From: emuller at adobe.com (Eric Muller) Date: Sun, 01 Jul 2007 10:07:11 -0700 Subject: Geographical boundaries for the continental US tz zones In-Reply-To: <465E634D.2080301@adobe.com> References: <465E634D.2080301@adobe.com> Message-ID: <4687DF3F.2080005@adobe.com> I have completed a first version of a map of the TZ timezones in the US. It is available as a shapefile at . Comments welcome, Eric. From CLawrence at stopwatchmaps.com Sun Jul 1 18:38:00 2007 From: CLawrence at stopwatchmaps.com (Christina Lawrence) Date: Sun, 1 Jul 2007 13:38:00 -0500 Subject: TimeZones and international waters In-Reply-To: <877ipxtcnp.fsf@penguin.cs.ucla.edu> Message-ID: Thank you for the response! What distance from shore defines "the territorial waters of any nation"? Is it nation specific, or an internationally recognized distance from shore? Thank you! Christina -----Original Message----- From: Paul Eggert [mailto:eggert at CS.UCLA.EDU] Sent: Thursday, June 21, 2007 12:56 PM To: tz at elsie.nci.nih.gov Cc: Christina Lawrence Subject: Re: TimeZones and international waters To help clear this up I'll add something like the following to my next proposed patch. Comments welcome. A ship within the territorial waters of any nation uses that nation's time. In international waters, time zone boundaries are meridians 15° apart, except that UTC−12 and UTC+12 are each 7.5° wide and are separated by the 180° meridian (not by the International Date Line, which is for land and territorial waters only). A captain can change ship's clocks any time after entering a new time zone; midnight changes are common. From pgoyette at juniper.net Sun Jul 1 18:50:08 2007 From: pgoyette at juniper.net (Paul Goyette) Date: Sun, 1 Jul 2007 11:50:08 -0700 Subject: TimeZones and international waters In-Reply-To: Message-ID: Generally, the territorial waters extend 12 miles from shore. In cases of conflict (ie, a point is less than 12 miles from the shores of two or more countries), the dividing line is established by treaty. I think there are still a few areas where treaties have not been adopted, so there might be some "gray" areas... International Treaties permit definition of "Economic Excclusion Zones" (the US EEZ is a 200-mile limit). Fishing limits apply in such areas, but boarding rights and controls over shipping etc. don not apply. Paul Goyette Juniper Networks Customer Service and former skipper of the 61' Cheoy Lee motor yacht "Gentle Wind" on her 2005 journey across the Pacific Ocean. > -----Original Message----- > From: Christina Lawrence [mailto:CLawrence at stopwatchmaps.com] > Sent: Sunday, July 01, 2007 11:38 AM > To: Paul Eggert > Cc: tz at lecserver.nci.nih.gov > Subject: RE: TimeZones and international waters > > Thank you for the response! > > What distance from shore defines "the territorial waters of > any nation"? > Is it nation specific, or an internationally recognized distance from > shore? > > Thank you! > > Christina > > > -----Original Message----- > From: Paul Eggert [mailto:eggert at CS.UCLA.EDU] > Sent: Thursday, June 21, 2007 12:56 PM > To: tz at elsie.nci.nih.gov > Cc: Christina Lawrence > Subject: Re: TimeZones and international waters > > To help clear this up I'll add something like the following to my next > proposed patch. Comments welcome. > > A ship within the territorial waters of any nation uses that nation's > time. In international waters, time zone boundaries are meridians > 15° apart, except that UTC−12 and UTC+12 are each 7.5° > wide and are separated by the 180° meridian (not by the > International Date Line, which is for land and territorial waters > only). A captain can change ship's clocks any time after entering a > new time zone; midnight changes are common. > From emuller at adobe.com Mon Jul 2 17:12:08 2007 From: emuller at adobe.com (Eric Muller) Date: Mon, 02 Jul 2007 10:12:08 -0700 Subject: French Polynesia Message-ID: <468931E8.7010206@adobe.com> If I read correctly the tz data for French Polynesia, there are three tz zones that are half an hour apart. I searched for an independent confirmation, but I can't find any evidence that FP has multiple local times. The best I have found so far is which suggests that all of FP is in a single timezone. Any idea of the source of the current data? Thanks, Eric. From wide.screen.software at mac.com Tue Jul 3 05:47:06 2007 From: wide.screen.software at mac.com (WIDE SCREEN SOFTWARE, LLC) Date: Mon, 2 Jul 2007 22:47:06 -0700 Subject: French Polynesia In-Reply-To: <468931E8.7010206@adobe.com> References: <468931E8.7010206@adobe.com> Message-ID: <379DAAE7-692F-4FF2-AD40-6301DBDEF615@mac.com> On Jul 2, 2007, at 10:12 AM, Eric Muller wrote: > If I read correctly the tz data for French Polynesia, there are > three tz zones that are half an hour apart. I searched for an > independent confirmation, but I can't find any evidence that FP has > multiple local times. The best I have found so far is > decouvrir_outre_mer/polynesie_francaise/ > publi_P_vie_pratique___decalage_horaire_1125327034760> > which suggests that all of FP is in a single timezone. > > Any idea of the source of the current data? > > Thanks, > Eric. > > > Eric, I am away working on location. I do not know if my wife had a chance to respond to your question. Check the following source that confirms the 3 time zones. http://home-4.tiscali.nl/~t876506/TZworld.html#pac If you have any questions please email. David Parrish (....on location) Wide Screen Software, LLC info at wide-screen.com http://www.wide-screen.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/tz/attachments/20070702/23b6c652/attachment.html From jnorgard at prodigy.net.mx Mon Jul 9 01:08:01 2007 From: jnorgard at prodigy.net.mx (Jesper Norgaard Welen) Date: Sun, 08 Jul 2007 20:08:01 -0500 Subject: French Polynesia time zones Message-ID: Perhaps the following link will interest Eric Muller and the rest of the mailing list members: http://www.timegenie.com/country.time/pf/ The FAQ mentioned of the Tahiti tourism web site in fact has the URL http://www.tahiti-tourisme.com/planner/tahitifaqs.asp (it seems to have changed name since timegenie site documented it). Eric asked for a recognition of the three time zones in the tz database for French Polynesia. The explanation in the timegenie web site is: "According to the official Tahiti Tourisme web site, Tahiti and her Islands have two times zones. This information can be found in the FAQ section. However, Tahiti and her islands have in fact three time zones. The third time zone is not mentioned on the Tahiti Tourisme web site. Most likely, the third time zone is not mentioned since it is not visited by many tourists due to its distance from the main island of Tahiti. Since there is no official mention of the third time zone, timegenie.com contacted a Tahiti Tourisme office by phone. The result was that timegenie.com received official confirmation of the third time zone. Based on the information provided by Tahiti Tourisme, the majority of the islands, including the island of Tahiti itself, are -10 hours UTC/GMT. The Marquesas Islands are -9 hours 30 minutes UTC/GMT. The Gambier Islands are the third time zone and they are -9 hours UTC/GMT." I hope it's alright to quote timegenie for this information. I haven't found myself an official French Polynesia goverment web site confirming this information, but my french is limited to a 40-hour course so it is not to much use in this investigation. Regards, - Jesper Jesper N?rgaard Welen Email: jnorgard at Prodigy.Net.mx Project Leader (L?der de Proyecto) Software CIMMYT - Centro Internacional de Mejoramiento de Ma?z y Trigo Direcci?n: CIMMYT Int. c/o Jesper N?rgaard Km. 45, Carretera M?xico-Veracruz El Bat?n Texcoco, Edo. de M?xico CP 56130 MEXICO Tel.: +52 (55) 58-04-20-04 ext. 1374 Fax: +52 (55) 58-04-75-58 Tel. Casa: 53-10-05-95 ? 53-10-97-78 Download the shareware program World Time Explorer, I made: http://www.worldtimeexplorer.com/index.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/tz/attachments/20070708/07a537d5/attachment.html From tkpublic at timklein.fastmail.fm Tue Jul 10 00:56:08 2007 From: tkpublic at timklein.fastmail.fm (Tim Klein) Date: Mon, 9 Jul 2007 19:56:08 -0500 Subject: Is there a list of "current" time zones? Message-ID: I'm new here. As I look through the tz database, and the archives of this mailing list, I realize what a phenomenal effort you folks have put in, to make all of this information available. Thank you for all you've done! A question... I'm helping to write an application that needs a menu for the user to choose what time zone they live in. With ~400 time zones in the database, that'd be a pretty daunting pull-down menu. But as I understand it, a significant fraction of the ~400 time zones exist only for historical reasons. Since our application will deal only with current and future times, historical distinctions don't matter, and we'd like the menu to show only the subset of time zones that are currently "in effect". (And we don't mind if it isn't painstakingly accurate or updated in real time.) Has anyone created such a list? Or maybe an algorithm (if not code) for generating one from the full database? I see that this question has come up in the past. To quote from the archives... ====== >From: "Andy Lipscomb" >Perhaps a better term would be "historical" time zones. This would >in fact be a useful distinction, since only a relatively small >subset of the timezones are necessary for applications that look >only forward--these would be the first set to present to a user for >selecting a time zone, with a "show all" option to get the complete >list. (For example, the 50 United States can be covered on a >forward-looking basis by eight zones--New York, Chicago, Denver, >Phoenix, Los Angeles, Anchorage, Adak, and Honolulu. And if one >takes as irrevocable the power of the EU over DST dates, then--for >example--London, Paris, and Helsinki would cover that entire area, >except for the different abbreviations used in the three +0 >countries.) ====== And... >From: Paul Eggert [mailto:eggert at CS.UCLA.EDU] >Sent: November 6, 2006 12:13 PM > >> Is there any way to flag some of the old historical zones such that >> they don't appear when running "tzselect"? > >We could have a table for people who don't care about historical >times, which maps zone names to "modern" zone names, and tzselect >could have an option to use that table. ====== Thank you very much for any wisdom on this subject! Tim Klein Dallas, Texas, USA From eulevik at gmail.com Tue Jul 10 01:56:21 2007 From: eulevik at gmail.com (Eric Ulevik) Date: Tue, 10 Jul 2007 11:56:21 +1000 Subject: Is there a list of "current" time zones? In-Reply-To: References: Message-ID: On 7/10/07, Tim Klein wrote: > I'm helping to write an application that needs a menu for the user to > choose what time zone they live in. With ~400 time zones in the > database, that'd be a pretty daunting pull-down menu. You will find this menu in quite a few places. Generally people don't have a problem identifying their geographical location - which is what this list shows. To simplify the menu, get the user to first choose a continent (eg. "Australia" or "Europe") then a region from a smaller list. You could also move the most common selections to the top of the list. Regards, Eric Ulevik From philip.howell at evalua.com.au Tue Jul 10 02:21:25 2007 From: philip.howell at evalua.com.au (Philip Howell) Date: Tue, 10 Jul 2007 12:21:25 +1000 Subject: Is there a list of "current" time zones? In-Reply-To: <"a06240819c2b88521e5ea(a)(091)192.168.1.104(093)*"@MHS> References: <"a06240819c2b88521e5ea(a)(091)192.168.1.104(093)*"@MHS> Message-ID: <4692ED25.4080904@evalua.com.au> Hi Tim, In the tzdata tarball is a file called zone.tab. It lists the current time zones grouped by country code. Cheers, Phil Tim Klein wrote: > I'm new here. As I look through the tz database, and the archives of > this mailing list, I realize what a phenomenal effort you folks have > put in, to make all of this information available. Thank you for all > you've done! > > A question... > > I'm helping to write an application that needs a menu for the user to > choose what time zone they live in. With ~400 time zones in the > database, that'd be a pretty daunting pull-down menu. > > But as I understand it, a significant fraction of the ~400 time zones > exist only for historical reasons. Since our application will deal > only with current and future times, historical distinctions don't > matter, and we'd like the menu to show only the subset of time zones > that are currently "in effect". (And we don't mind if it isn't > painstakingly accurate or updated in real time.) > > Has anyone created such a list? Or maybe an algorithm (if not code) > for generating one from the full database? > > I see that this question has come up in the past. To quote from the > archives... > > ====== > >> From: "Andy Lipscomb" >> Perhaps a better term would be "historical" time zones. This would in >> fact be a useful distinction, since only a relatively small subset of >> the timezones are necessary for applications that look only >> forward--these would be the first set to present to a user for >> selecting a time zone, with a "show all" option to get the complete >> list. (For example, the 50 United States can be covered on a >> forward-looking basis by eight zones--New York, Chicago, Denver, >> Phoenix, Los Angeles, Anchorage, Adak, and Honolulu. And if one takes >> as irrevocable the power of the EU over DST dates, then--for >> example--London, Paris, and Helsinki would cover that entire area, >> except for the different abbreviations used in the three +0 countries.) > > ====== > And... > >> From: Paul Eggert [mailto:eggert at CS.UCLA.EDU] >> Sent: November 6, 2006 12:13 PM >> >>> Is there any way to flag some of the old historical zones such that >>> they don't appear when running "tzselect"? >> >> We could have a table for people who don't care about historical >> times, which maps zone names to "modern" zone names, and tzselect >> could have an option to use that table. > > ====== > > Thank you very much for any wisdom on this subject! > > Tim Klein > Dallas, Texas, USA > > From olsona at dc37a.nci.nih.gov Tue Jul 10 13:29:20 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Tue, 10 Jul 2007 09:29:20 -0400 Subject: FW: Time Zone mapping --> Windows ??? Message-ID: I'm forwarding this message from Boris Lang, who is not on the time zone mailing list. Those of you who are on the time zone mailing list should direct replies appropriately. --ado -----Original Message----- From: BORIS LANG [mailto:BORIS.LANG at MEMO.IKEA.COM] Sent: Tuesday, July 10, 2007 8:55 AM To: tz at lecserver.nci.nih.gov Subject: Time Zone mapping --> Windows ??? --- Received from IKEA4.BRLG +49 6122 5858276 07-07-10 14.56 -------------------------------------- Hi, we are working on the implementation of time zone information into an application using the tz database. TZ data names will be our main type but we also need to do a mapping to the time zone names used in windows. i.e. Europe/Berlin (tzd) --> Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna (Windows) The problem is that I can?t find a complete list that contains the mapping from tz database to windows. Can somebody please help us? Is there already such a list existing? Best regards Boris Lang ------ IKEA IT Germany GmbH Am Wandersmann 2-4 65719 Hofheim-Wallau Sitz M?nchen HR B 79392, Amtsgericht M?nchen Gesch?ftsf?hrer: Manfred Godlewski, G?ran Sj?strand, Ola Troedsson ---- 07-07-10 14.56 ---- Sent to --------------------------------------------------------------------------------- -> tz at elsie.nci.nih.gov From GMANE at faerber.muc.de Tue Jul 10 09:42:23 2007 From: GMANE at faerber.muc.de (=?ISO-8859-1?Q?Claus_F=E4rber?=) Date: Tue, 10 Jul 2007 11:42:23 +0200 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: References: Message-ID: Andy Lipscomb schrieb: > As was largely hashed out over China, changing to Hanoi would in fact *not* be consistent--the standard is largest city, not necessarily capital. (For example, Australia, Canada, China, India, New Zealand, South Africa, and the USA do not have explicit listings for their capital cities.) I argued that Beijing should be in because of its significance in determining Chinese-calendar dates, but lost that one. As for what to call any given city, on that I have no opinion. As the term city is ambiguous, the standard is ambiguous and inconsistent anyway. If city is defined as municipality, the following are wrong: Europe/London should be Europe/Birmingham Asia/Tokyo should be Asia/Yokohama Australia/Sydney should be Australia/Blacktown ... and probably dozens others. The largest "cities" often consist of multiple municipalities, which makes this definition insensible. However, if city is defined as metropolitan area, the following are clearly wrong: Europe/Berlin should be Europe/Rhein-Rhur Europe/Rome should be Europe/Milan Asia/Calcutta should be Asia/Mumbai Asia/Karachi should be Asia/Lahor IMO, the standard should be changed from "largest city" to "most important city". Importance would be primarily derived from the population count but with respect to factors such as legal status (city, capital) and views of the local population. Claus From dot at dotat.at Tue Jul 10 14:59:31 2007 From: dot at dotat.at (Tony Finch) Date: Tue, 10 Jul 2007 15:59:31 +0100 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: References: Message-ID: On Tue, 10 Jul 2007, Claus F?rber wrote: > > If city is defined as municipality, the following are wrong: > > Europe/London should be Europe/Birmingham Not if it's London as in the Greater London Authority (or, historically, the Greater London Council, the London County Council, etc.), as opposed to the City of London which has been only a small part of the geography and government of the greater city for centuries. Tony. -- f.a.n.finch http://dotat.at/ IRISH SEA: NORTHWEST 4 OR 5, OCCASIONALLY 6. SLIGHT OR MODERATE. SHOWERS. MAINLY GOOD. From GMANE at faerber.muc.de Tue Jul 10 16:13:14 2007 From: GMANE at faerber.muc.de (=?UTF-8?B?Q2xhdXMgRsOkcmJlcg==?=) Date: Tue, 10 Jul 2007 18:13:14 +0200 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: References: Message-ID: Tony Finch schrieb: > On Tue, 10 Jul 2007, Claus F?rber wrote: >> If city is defined as municipality, the following are wrong: >> >> Europe/London should be Europe/Birmingham > > Not if it's London as in the Greater London Authority (or, historically, > the Greater London Council, the London County Council, etc.), as opposed > to the City of London which has been only a small part of the geography > and government of the greater city for centuries. The GLA is a super-city authority, covering multiple cities such as the City of London, the City of Westminster, etc. Well, that just proves my point that the term "city" introduces ambiguity. It's simply inconsistent to treat Greater London as a "city", which is made up of multiple municipalities like the City of London, Westminster, etc., but not the Ruhrgebiet (5.3 million and thus larger than Berlin, 3.4 million), which is made up of municipalities like Essen, Bochum or Dortmund and also has a super-city authority: the Regionalverband Ruhr (RVR). It's also inconsistent to treat Greater London as a "city" and not Greater Milan (7 million), which would be substantially larger than Rome or Greater Rome (2.5 or 3.3 million). Bending the rules in similar ways, Shanghai (??) suddenly has a population of 9.4 millions (the agglomeration, not the larger administrative area) and Beijing (??) has 11.5 millions (the agglomeration, not the administrative area and not the "core city"). It does not work with Saigon/Ho Chi Minh City (Th?nh ph? H? Ch? Minh) and Hanoi (H? N?i), though. Claus From vuntz at gnome.org Tue Jul 10 17:23:50 2007 From: vuntz at gnome.org (Vincent Untz) Date: Tue, 10 Jul 2007 19:23:50 +0200 Subject: Localization of timezones from zone.tab Message-ID: <20070710172350.GI30640@vuntz.net> Hi, [please keep me cc'ed since I'm not subscribed to this list] I know that, at least in GNOME, there are now three places where we parse zone.tab to get a list of timezones supported by the OS. I suppose other projects are also doing this. This list is then presented to the user to let him choose the timezone. The problem here is that we let the user choose strings which look like "Antarctica/South_Pole". This is not really good for non-english-speaking people ;-) Of course, we can add all the timezones to our list of strings to translate, but this means all projects needing to do so will duplicate this work and the translations. I'd like the tz database to ship translations in po files. This would imply the following: + create a small script to generate a POT file from zone.tab (easy) + submit the POT file to the translation project [1] (or any other place that helps with translation) + add the po files for translation to the tz database + choose a gettext domain (Of course, I'm quite probably forgetting about a step :-)) I've seen that this topic has been discussed before [2], but the proposition there was really more ambitious, so I'm hoping a simple approach would be welcomed. What do you think? Thanks, [1] http://translationproject.org/ [2] http://osdir.com/ml/time.tz/2004-09/msg00000.html Vincent -- Les gens heureux ne sont pas press?s. From olsona at dc37a.nci.nih.gov Tue Jul 10 17:26:23 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Tue, 10 Jul 2007 13:26:23 -0400 Subject: FW: Localization of timezones from zone.tab Message-ID: I'm forwarding this message from Vincent Untz, who is not on the time zone mailing list. Those of you who are on the time zone mailing list should direct replies appropriately. --ado -----Original Message----- From: Vincent Untz [mailto:vuntz at gnome.org] Sent: Tuesday, July 10, 2007 1:24 PM To: tz at lecserver.nci.nih.gov Subject: Localization of timezones from zone.tab Hi, [please keep me cc'ed since I'm not subscribed to this list] I know that, at least in GNOME, there are now three places where we parse zone.tab to get a list of timezones supported by the OS. I suppose other projects are also doing this. This list is then presented to the user to let him choose the timezone. The problem here is that we let the user choose strings which look like "Antarctica/South_Pole". This is not really good for non-english-speaking people ;-) Of course, we can add all the timezones to our list of strings to translate, but this means all projects needing to do so will duplicate this work and the translations. I'd like the tz database to ship translations in po files. This would imply the following: + create a small script to generate a POT file from zone.tab (easy) + submit the POT file to the translation project [1] (or any other place that helps with translation) + add the po files for translation to the tz database + choose a gettext domain (Of course, I'm quite probably forgetting about a step :-)) I've seen that this topic has been discussed before [2], but the proposition there was really more ambitious, so I'm hoping a simple approach would be welcomed. What do you think? Thanks, [1] http://translationproject.org/ [2] http://osdir.com/ml/time.tz/2004-09/msg00000.html Vincent -- Les gens heureux ne sont pas press?s. From AndyLipscomb at decosimo.com Tue Jul 10 17:34:11 2007 From: AndyLipscomb at decosimo.com (Andy Lipscomb) Date: Tue, 10 Jul 2007 13:34:11 -0400 Subject: Localization of timezones from zone.tab In-Reply-To: Message-ID: Currently, the main effort to localize time-zone information is in the Common Language Data Repository (I think that's what it's called, I know it's CLDR for initials), hosted at http://www.unicode.org/cldr; for each zone, there is the option to localize two names (DST and standard), the initials for those names, and the example city. J Andrew Lipscomb, CPA*ABV, ASA Decosimo Corporate Finance 900 Tallan Building 2 Union Square Chattanooga, TN 37402 423.756.7100 Fax 423.266.6671 www.dcf.decosimo.com -----Original Message----- From: Olson, Arthur David (NIH/NCI) [E] [mailto:olsona at dc37a.nci.nih.gov] Sent: Tue 10 July 2007 13:26 To: tz at lecserver.nci.nih.gov Cc: vuntz at gnome.org Subject: FW: Localization of timezones from zone.tab I'm forwarding this message from Vincent Untz, who is not on the time zone mailing list. Those of you who are on the time zone mailing list should direct replies appropriately. --ado -----Original Message----- From: Vincent Untz [mailto:vuntz at gnome.org] Sent: Tuesday, July 10, 2007 1:24 PM To: tz at lecserver.nci.nih.gov Subject: Localization of timezones from zone.tab Hi, [please keep me cc'ed since I'm not subscribed to this list] I know that, at least in GNOME, there are now three places where we parse zone.tab to get a list of timezones supported by the OS. I suppose other projects are also doing this. This list is then presented to the user to let him choose the timezone. The problem here is that we let the user choose strings which look like "Antarctica/South_Pole". This is not really good for non-english-speaking people ;-) Of course, we can add all the timezones to our list of strings to translate, but this means all projects needing to do so will duplicate this work and the translations. I'd like the tz database to ship translations in po files. This would imply the following: + create a small script to generate a POT file from zone.tab (easy) + submit the POT file to the translation project [1] (or any other place that helps with translation) + add the po files for translation to the tz database + choose a gettext domain (Of course, I'm quite probably forgetting about a step :-)) I've seen that this topic has been discussed before [2], but the proposition there was really more ambitious, so I'm hoping a simple approach would be welcomed. What do you think? Thanks, [1] http://translationproject.org/ [2] http://osdir.com/ml/time.tz/2004-09/msg00000.html Vincent -- Les gens heureux ne sont pas press?s. From mark.davis at icu-project.org Tue Jul 10 17:44:14 2007 From: mark.davis at icu-project.org (Mark Davis) Date: Tue, 10 Jul 2007 10:44:14 -0700 Subject: FW: Localization of timezones from zone.tab In-Reply-To: References: Message-ID: <30b660a20707101044n2c21c123l19f9b718d4bb5050@mail.gmail.com> The Unicode CLDR project (http://unicode.org/cldr/) does supply translations for timezone IDs. There are a few caveats. 1. The timezone database really has equivalence classes of IDs. One of these can be used as a representative for any in the equivalence class. It is the zone.tab file that contains such IDs. CLDR started by using that file, but unfortunately it is not stable (different equivalent IDs can be substituted at any time). So what we do is use as the representative the one that historically the first one used in any zone.tab file (after CLDR started). 2. We allow, but do not encourage, translation of zones that are the only zone in a country. For that we use the country name. This cuts down very substantially on the number of translations needed. That is, you would see the equivalent of "Italy", and "United States (Los Angeles)" -- only in the latter case do we need translations for the cities. 3. Translators can optionally add other variations: daylight (summer) time, standard (winter) time, and generic time, both abbreviated and long. 4. These choices percolate out to clients of CLDR: Google, IBM, Apple, Adobe, and many others. Mark On 7/10/07, Olson, Arthur David (NIH/NCI) [E] wrote: > > I'm forwarding this message from Vincent Untz, who is not on the time zone > mailing list. > > Those of you who are on the time zone mailing list should direct replies > appropriately. > > --ado > > -----Original Message----- > From: Vincent Untz [mailto:vuntz at gnome.org] > Sent: Tuesday, July 10, 2007 1:24 PM > To: tz at lecserver.nci.nih.gov > Subject: Localization of timezones from zone.tab > > Hi, > > [please keep me cc'ed since I'm not subscribed to this list] > > I know that, at least in GNOME, there are now three places where we > parse zone.tab to get a list of timezones supported by the OS. I suppose > other projects are also doing this. This list is then presented to the > user to let him choose the timezone. > > The problem here is that we let the user choose strings which look like > "Antarctica/South_Pole". This is not really good for > non-english-speaking people ;-) > > Of course, we can add all the timezones to our list of strings to > translate, but this means all projects needing to do so will duplicate > this work and the translations. > > I'd like the tz database to ship translations in po files. This would > imply the following: > > + create a small script to generate a POT file from zone.tab (easy) > + submit the POT file to the translation project [1] (or any other > place that helps with translation) > + add the po files for translation to the tz database > + choose a gettext domain > > (Of course, I'm quite probably forgetting about a step :-)) > > I've seen that this topic has been discussed before [2], but the > proposition there was really more ambitious, so I'm hoping a simple > approach would be welcomed. > > What do you think? > > Thanks, > > [1] http://translationproject.org/ > [2] http://osdir.com/ml/time.tz/2004-09/msg00000.html > > Vincent > > -- > Les gens heureux ne sont pas press?s. > -- Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/tz/attachments/20070710/f31b97a1/attachment.html From rlaw at nc.rr.com Tue Jul 10 18:38:02 2007 From: rlaw at nc.rr.com (rlaw at nc.rr.com) Date: Tue, 10 Jul 2007 14:38:02 -0400 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: References: Message-ID: > As the term city is ambiguous, the standard is ambiguous and > inconsistent anyway. How can we put an end to the incessant disputation over time zone identifiers? If we go by metropolitan area populations, someone will say we should go by central city populations. If we use any criterion that chooses Hanoi, someone will say Ho Chi Minh City is more important; but others will argue that the capital city is always more important. We must bear in mind that these are only supposed to be identifiers. Conceptually, we could be using WT/QAF just as well as Europe/Rome. It was merely for the convenience of developers that mnemonic names were chosen. But it is the responsibility of a user interface, not of the tz database, to translate the time zone identifiers into user-friendly names. The volunteer maintainers of the tz database have plenty of work to do, just to keep it up to date. If their job description is expanded to include making sure that the definitions of cities are consistent, providing universally acceptable names and abbreviations for time zones, or enabling localization by giving the translations of city, country, and time zone names into an arbitrary number of languages, I believe that puts too much on their plate. Presumably the CLDR addresses localization issues. Whoever maintains the CLDR has undertaken responsibility for interpreting the identifiers into human-readable form. Identifiers should be stable, too. True, by using backward-compatibility links, we can minimize the disruption caused by changing an identifier. Still, any kind of change has its cost, and a lot of the cost is hidden. We don't know how many people have used "Europe/Rome" somewhere in their code or nomenclature or documentation, and would deem it necessary to change the string if the primary name of that time zone changed to "Europe/Milan". (Of course, some changes are unavoidable, when time zones split.) My suggestion would be to state boldly in the documentation, "Time zone identifiers are arbitrary. Although they look as if they have a geographic interpretation, there is no guarantee that they do, or will continue to in the future. They should not be displayed directly to end users." Then, if possible, there should be some discussion of how to display time zone information to users. If we get GIS files for time zone boundaries, that will be a big help. Maintaining the boundary files would fall within the purview of the tz mailing list. Gwillim Law From chucks2 at veladg.com Tue Jul 10 20:37:17 2007 From: chucks2 at veladg.com (Chuck Soper) Date: Tue, 10 Jul 2007 13:37:17 -0700 Subject: FW: Localization of timezones from zone.tab Message-ID: I've been on the tz list for several years. I have tried to follow the Time Zone Localizations topic for CLDR. I do not understand why translations would be supplied for timezone IDs (tzIDs). Many tzIDs refer to the same time zone name. For example, I believe that Argentina has 2 time zone names, yet it has 10 tzIDs to handle DST rules for various states. Does this mean that 20 localized names would be required for Argentina? Does this mean that a new tzID would not be localized? Looking at 381 tzIDs of a tzData version (from 2006), I multiply it by two (for std and dst names) to obtain 762 time zone names required. By removing names of tzIDs that do not recognize DST and removing tzIDs that refer to the same time name (e.g. many tzIDs refer to Central European Time), I was to reduce total time zone names from 762 to 212. Can over 500 names can be removed from the translation list? Multiplying 500 potentially unneeded names by the number of translations would result in a large reduction of translation efforts. My approach is dependent on having a stable list of time zone names. As far as I know, such a list does not exist. If such a list existed, I would envision tzIDs being mapped to the 'time zone name' list. Chuck At 10:44 AM -0700 7/10/07, Mark Davis wrote: >The Unicode CLDR project >(http://unicode.org/cldr/) >does supply translations for timezone IDs. There >are a few caveats. > >1. The timezone database really has >equivalence classes of IDs. One of these can be >used as a representative for any in the >equivalence class. It is the zone.tab file that >contains such IDs. CLDR started by using that >file, but unfortunately it is not stable >(different equivalent IDs can be substituted at >any time). So what we do is use as the >representative the one that historically the >first one used in any zone.tab file (after CLDR >started). >2. We allow, but do not encourage, >translation of zones that are the only zone in a >country. For that we use the country name. This >cuts down very substantially on the number of >translations needed. That is, you would see the >equivalent of "Italy", and "United States (Los >Angeles)" -- only in the latter case do we need >translations for the cities. >3. Translators can optionally add other >variations: daylight (summer) time, standard >(winter) time, and generic time, both >abbreviated and long. >4. These choices percolate out to clients of >CLDR: Google, IBM, Apple, Adobe, and many others. > >Mark > >On 7/10/07, Olson, Arthur David (NIH/NCI) [E] ><olsona at dc37a.nci.nih.gov> >wrote: > >I'm forwarding this message from Vincent Untz, >who is not on the time zone mailing list. > >Those of you who are on the time zone mailing >list should direct replies appropriately. > > --ado > >-----Original Message----- >From: Vincent Untz [mailto: vuntz at gnome.org] >Sent: Tuesday, July 10, 2007 1:24 PM >To: tz at lecserver.nci.nih.gov >Subject: Localization of timezones from zone.tab > >Hi, > >[please keep me cc'ed since I'm not subscribed to this list] > >I know that, at least in GNOME, there are now three places where we >parse zone.tab to get a list of timezones supported by the OS. I suppose >other projects are also doing this. This list is then presented to the >user to let him choose the timezone. > >The problem here is that we let the user choose strings which look like >"Antarctica/South_Pole". This is not really good for >non-english-speaking people ;-) > >Of course, we can add all the timezones to our list of strings to >translate, but this means all projects needing to do so will duplicate >this work and the translations. > >I'd like the tz database to ship translations in po files. This would >imply the following: > >+ create a small script to generate a POT file from zone.tab (easy) >+ submit the POT file to the translation project [1] (or any other > place that helps with translation) >+ add the po files for translation to the tz database >+ choose a gettext domain > >(Of course, I'm quite probably forgetting about a step :-)) > >I've seen that this topic has been discussed before [2], but the >proposition there was really more ambitious, so I'm hoping a simple >approach would be welcomed. > >What do you think? > >Thanks, > >[1] http://translationproject.org/ >[2] > >http://osdir.com/ml/time.tz/2004-09/msg00000.html > >Vincent > >-- >Les gens heureux ne sont pas press?s. > > > > >-- >Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/tz/attachments/20070710/4371bf99/attachment.html From mark.davis at icu-project.org Tue Jul 10 20:54:19 2007 From: mark.davis at icu-project.org (Mark Davis) Date: Tue, 10 Jul 2007 13:54:19 -0700 Subject: FW: Localization of timezones from zone.tab In-Reply-To: References: Message-ID: <30b660a20707101354o58134e03l817d61b0778af44c@mail.gmail.com> We have actually instituted an alternative mechanism called 'metazones', which are somewhat like what you describe. They basically coalesce zones that have the same behavior in modern time. However, they have some further restrictions, and we only put this in recently thus haven't gathered enough data to be useful yet. Mark On 7/10/07, Chuck Soper wrote: > > I've been on the tz list for several years. I have tried to follow the > Time Zone Localizations topic for CLDR. > > I do not understand why translations would be supplied for timezone IDs > (tzIDs). Many tzIDs refer to the same time zone name. For example, I believe > that Argentina has 2 time zone names, yet it has 10 tzIDs to handle DST > rules for various states. Does this mean that 20 localized names would be > required for Argentina? Does this mean that a new tzID would not be > localized? > > Looking at 381 tzIDs of a tzData version (from 2006), I multiply it by two > (for std and dst names) to obtain 762 time zone names required. By removing > names of tzIDs that do not recognize DST and removing tzIDs that refer to > the same time name (e.g. many tzIDs refer to Central European Time), I was > to reduce total time zone names from 762 to 212. > > Can over 500 names can be removed from the translation list? Multiplying > 500 potentially unneeded names by the number of translations would result in > a large reduction of translation efforts. > > My approach is dependent on having a stable list of time zone names. As > far as I know, such a list does not exist. If such a list existed, I would > envision tzIDs being mapped to the 'time zone name' list. > > Chuck > > > At 10:44 AM -0700 7/10/07, Mark Davis wrote: > > The Unicode CLDR project (http://unicode.org/cldr/) does supply > translations for timezone IDs. There are a few caveats. > > 1. The timezone database really has equivalence classes of IDs. One > of these can be used as a representative for any in the equivalence class. > It is the zone.tab file that contains such IDs. CLDR started by using that > file, but unfortunately it is not stable (different equivalent IDs can be > substituted at any time). So what we do is use as the representative the one > that historically the first one used in any zone.tab file (after CLDR > started). > > 2. We allow, but do not encourage, translation of zones that are the > only zone in a country. For that we use the country name. This cuts down > very substantially on the number of translations needed. That is, you would > see the equivalent of "Italy", and "United States (Los Angeles)" -- only in > the latter case do we need translations for the cities. > > 3. Translators can optionally add other variations: daylight (summer) > time, standard (winter) time, and generic time, both abbreviated and long. > > 4. These choices percolate out to clients of CLDR: Google, IBM, > Apple, Adobe, and many others. > > Mark > > On 7/10/07,* Olson, Arthur David (NIH/NCI) [E]* > wrote: > > I'm forwarding this message from Vincent Untz, who is not on the time zone > mailing list. > > Those of you who are on the time zone mailing list should direct replies > appropriately. > > --ado > > -----Original Message----- > From: Vincent Untz [mailto: vuntz at gnome.org] > Sent: Tuesday, July 10, 2007 1:24 PM > To: tz at lecserver.nci.nih.gov > Subject: Localization of timezones from zone.tab > > Hi, > > [please keep me cc'ed since I'm not subscribed to this list] > > I know that, at least in GNOME, there are now three places where we > parse zone.tab to get a list of timezones supported by the OS. I suppose > other projects are also doing this. This list is then presented to the > user to let him choose the timezone. > > The problem here is that we let the user choose strings which look like > "Antarctica/South_Pole". This is not really good for > non-english-speaking people ;-) > > Of course, we can add all the timezones to our list of strings to > translate, but this means all projects needing to do so will duplicate > this work and the translations. > > I'd like the tz database to ship translations in po files. This would > imply the following: > > + create a small script to generate a POT file from zone.tab (easy) > + submit the POT file to the translation project [1] (or any other > > place that helps with translation) > > + add the po files for translation to the tz database > + choose a gettext domain > > (Of course, I'm quite probably forgetting about a step :-)) > > I've seen that this topic has been discussed before [2], but the > proposition there was really more ambitious, so I'm hoping a simple > approach would be welcomed. > > What do you think? > > Thanks, > > [1] http://translationproject.org/ > [2] http://osdir.com/ml/time.tz/2004-09/msg00000.html > > Vincent > > -- > Les gens heureux ne sont pas press?s. > > > > > -- > Mark > > > -- Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/tz/attachments/20070710/1bb18f83/attachment.html From chucks2 at veladg.com Tue Jul 10 21:49:10 2007 From: chucks2 at veladg.com (Chuck Soper) Date: Tue, 10 Jul 2007 14:49:10 -0700 Subject: FW: Localization of timezones from zone.tab In-Reply-To: <30b660a20707101354o58134e03l817d61b0778af44c@mail.gmail.com> References: <30b660a20707101354o58134e03l817d61b0778af44c@mail.gmail.com> Message-ID: Thanks for your response. I now remember meeting someone from IBM at an IMUG meeting at Apple; he described metazones. What is the best way for me to stay informed of CLDR related to time zones? And is there a way to make comments, suggestions or discuss? Chuck At 1:54 PM -0700 7/10/07, Mark Davis wrote: >We have actually instituted an alternative >mechanism called 'metazones', which are somewhat >like what you describe. They basically coalesce >zones that have the same behavior in modern >time. However, they have some further >restrictions, and we only put this in recently >thus haven't gathered enough data to be useful >yet. > >Mark > >On 7/10/07, Chuck Soper <chucks2 at veladg.com> wrote: > >I've been on the tz list for several years. I >have tried to follow the Time Zone Localizations >topic for CLDR. > >I do not understand why translations would be >supplied for timezone IDs (tzIDs). Many tzIDs >refer to the same time zone name. For example, I >believe that Argentina has 2 time zone names, >yet it has 10 tzIDs to handle DST rules for >various states. Does this mean that 20 localized >names would be required for Argentina? Does this >mean that a new tzID would not be localized? > >Looking at 381 tzIDs of a tzData version (from >2006), I multiply it by two (for std and dst >names) to obtain 762 time zone names required. >By removing names of tzIDs that do not recognize >DST and removing tzIDs that refer to the same >time name (e.g. many tzIDs refer to Central >European Time), I was to reduce total time zone >names from 762 to 212. > >Can over 500 names can be removed from the >translation list? Multiplying 500 potentially >unneeded names by the number of translations >would result in a large reduction of translation >efforts. > >My approach is dependent on having a stable list >of time zone names. As far as I know, such a >list does not exist. If such a list existed, I >would envision tzIDs being mapped to the 'time >zone name' list. > >Chuck > > >At 10:44 AM -0700 7/10/07, Mark Davis wrote: > >>The Unicode CLDR project >>(http://unicode.org/cldr/) >>does supply translations for timezone IDs. >>There are a few caveats. >> >>1. The timezone database really has >>equivalence classes of IDs. One of these can be >>used as a representative for any in the >>equivalence class. It is the zone.tab file that >>contains such IDs. CLDR started by using that >>file, but unfortunately it is not stable >>(different equivalent IDs can be substituted at >>any time). So what we do is use as the >>representative the one that historically the >>first one used in any zone.tab file (after CLDR >>started). >> >>2. We allow, but do not encourage, >>translation of zones that are the only zone in >>a country. For that we use the country name. >>This cuts down very substantially on the number >>of translations needed. That is, you would see >>the equivalent of "Italy", and "United States >>(Los Angeles)" -- only in the latter case do we >>need translations for the cities. >> >>3. Translators can optionally add other >>variations: daylight (summer) time, standard >>(winter) time, and generic time, both >>abbreviated and long. >> >>4. These choices percolate out to clients >>of CLDR: Google, IBM, Apple, Adobe, and many >>others. >> >Mark > >On 7/10/07, Olson, Arthur David (NIH/NCI) [E] ><olsona at dc37a.nci.nih.gov> >wrote: > >I'm forwarding this message from Vincent Untz, >who is not on the time zone mailing list. > >Those of you who are on the time zone mailing >list should direct replies appropriately. > > --ado > >-----Original Message----- >From: Vincent Untz [mailto: vuntz at gnome.org] >Sent: Tuesday, July 10, 2007 1:24 PM >To: tz at lecserver.nci.nih.gov >Subject: Localization of timezones from zone.tab > >Hi, > >[please keep me cc'ed since I'm not subscribed to this list] > >I know that, at least in GNOME, there are now three places where we >parse zone.tab to get a list of timezones supported by the OS. I suppose >other projects are also doing this. This list is then presented to the >user to let him choose the timezone. > >The problem here is that we let the user choose strings which look like >"Antarctica/South_Pole". This is not really good for >non-english-speaking people ;-) > >Of course, we can add all the timezones to our list of strings to >translate, but this means all projects needing to do so will duplicate >this work and the translations. > >I'd like the tz database to ship translations in po files. This would >imply the following: > >+ create a small script to generate a POT file from zone.tab (easy) >+ submit the POT file to the translation project [1] (or any other > > place that helps with translation) > >+ add the po files for translation to the tz database >+ choose a gettext domain > >(Of course, I'm quite probably forgetting about a step :-)) > >I've seen that this topic has been discussed before [2], but the >proposition there was really more ambitious, so I'm hoping a simple >approach would be welcomed. > >What do you think? > >Thanks, > >[1] http://translationproject.org/ >[2] > >http://osdir.com/ml/time.tz/2004-09/msg00000.html > >Vincent > >-- >Les gens heureux ne sont pas press?s. > > > > >-- >Mark > > > > > >-- >Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/tz/attachments/20070710/a12e1b21/attachment.html From mark.davis at icu-project.org Tue Jul 10 22:05:53 2007 From: mark.davis at icu-project.org (Mark Davis) Date: Tue, 10 Jul 2007 15:05:53 -0700 Subject: FW: Localization of timezones from zone.tab In-Reply-To: References: <30b660a20707101354o58134e03l817d61b0778af44c@mail.gmail.com> Message-ID: <30b660a20707101505g3d545171o43fbf84ed35d6c59@mail.gmail.com> There is a users group at http://www.unicode.org/consortium/distlist.html#cldr_list. You can post suggestions/requests via the bug form on http://www.unicode.org/cldr/bugs/locale-bugs. If you belong to a Unicode member organization (http://www.unicode.org/consortium/memblogo.html) you can get on the internal list and even (if you choose) the weekly teleconference. Mark On 7/10/07, Chuck Soper wrote: > > Thanks for your response. I now remember meeting someone from IBM at an > IMUG meeting at Apple; he described metazones. > > What is the best way for me to stay informed of CLDR related to time > zones? And is there a way to make comments, suggestions or discuss? > > Chuck > > At 1:54 PM -0700 7/10/07, Mark Davis wrote: > > We have actually instituted an alternative mechanism called 'metazones', > which are somewhat like what you describe. They basically coalesce zones > that have the same behavior in modern time. However, they have some further > restrictions, and we only put this in recently thus haven't gathered enough > data to be useful yet. > > Mark > > On 7/10/07,* Chuck Soper* wrote: > > I've been on the tz list for several years. I have tried to follow the > Time Zone Localizations topic for CLDR. > > > I do not understand why translations would be supplied for timezone IDs > (tzIDs). Many tzIDs refer to the same time zone name. For example, I believe > that Argentina has 2 time zone names, yet it has 10 tzIDs to handle DST > rules for various states. Does this mean that 20 localized names would be > required for Argentina? Does this mean that a new tzID would not be > localized? > > > Looking at 381 tzIDs of a tzData version (from 2006), I multiply it by two > (for std and dst names) to obtain 762 time zone names required. By removing > names of tzIDs that do not recognize DST and removing tzIDs that refer to > the same time name (e.g. many tzIDs refer to Central European Time), I was > to reduce total time zone names from 762 to 212. > > > Can over 500 names can be removed from the translation list? Multiplying > 500 potentially unneeded names by the number of translations would result in > a large reduction of translation efforts. > > > My approach is dependent on having a stable list of time zone names. As > far as I know, such a list does not exist. If such a list existed, I would > envision tzIDs being mapped to the 'time zone name' list. > > > Chuck > > > > At 10:44 AM -0700 7/10/07, Mark Davis wrote: > > The Unicode CLDR project (http://unicode.org/cldr/) does supply > translations for timezone IDs. There are a few caveats. > > 1. The timezone database really has equivalence classes of IDs. One > of these can be used as a representative for any in the equivalence class. > It is the zone.tab file that contains such IDs. CLDR started by using that > file, but unfortunately it is not stable (different equivalent IDs can be > substituted at any time). So what we do is use as the representative the one > that historically the first one used in any zone.tab file (after CLDR > started). > > 2. We allow, but do not encourage, translation of zones that are the > only zone in a country. For that we use the country name. This cuts down > very substantially on the number of translations needed. That is, you would > see the equivalent of "Italy", and "United States (Los Angeles)" -- only in > the latter case do we need translations for the cities. > > 3. Translators can optionally add other variations: daylight (summer) > time, standard (winter) time, and generic time, both abbreviated and long. > > 4. These choices percolate out to clients of CLDR: Google, IBM, > Apple, Adobe, and many others. > > Mark > > On 7/10/07,* Olson, Arthur David (NIH/NCI) [E]* > wrote: > > I'm forwarding this message from Vincent Untz, who is not on the time zone > mailing list. > > Those of you who are on the time zone mailing list should direct replies > appropriately. > > --ado > > -----Original Message----- > From: Vincent Untz [mailto: vuntz at gnome.org] > Sent: Tuesday, July 10, 2007 1:24 PM > To: tz at lecserver.nci.nih.gov > Subject: Localization of timezones from zone.tab > > Hi, > > [please keep me cc'ed since I'm not subscribed to this list] > > I know that, at least in GNOME, there are now three places where we > > parse zone.tab to get a list of timezones supported by the OS. I suppose > other projects are also doing this. This list is then presented to the > user to let him choose the timezone. > > The problem here is that we let the user choose strings which look like > "Antarctica/South_Pole". This is not really good for > non-english-speaking people ;-) > > Of course, we can add all the timezones to our list of strings to > translate, but this means all projects needing to do so will duplicate > this work and the translations. > > I'd like the tz database to ship translations in po files. This would > imply the following: > > + create a small script to generate a POT file from zone.tab (easy) > + submit the POT file to the translation project [1] (or any other > > place that helps with translation) > > + add the po files for translation to the tz database > + choose a gettext domain > > (Of course, I'm quite probably forgetting about a step :-)) > > I've seen that this topic has been discussed before [2], but the > proposition there was really more ambitious, so I'm hoping a simple > approach would be welcomed. > > What do you think? > > Thanks, > > [1] http://translationproject.org/ > [2] http://osdir.com/ml/time.tz/2004-09/msg00000.html > > Vincent > > -- > Les gens heureux ne sont pas press?s. > > > > > -- > Mark > > > > > > -- > Mark > > > -- Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/tz/attachments/20070710/0606e527/attachment.html From Paul.Schauble at ticketmaster.com Tue Jul 10 22:12:44 2007 From: Paul.Schauble at ticketmaster.com (Paul Schauble) Date: Tue, 10 Jul 2007 15:12:44 -0700 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: References: Message-ID: <0165EECEBB4CF745ACF095E1176B03EA12C7FFE3@SUNCA-EXB-AV1.ticketmaster.corp> I suggested some time ago that zones should be named according to the authority that declared the zone. This would often result in country names or country name (subdivision). But it would also clearly identify things like "Navajo Time" as such rather than lumping this in with "Denver". I think this gives a more stable system that largest city. It completely avoids the issues of what is a city. And it avoids changing zone names when city population changes. ++PLS -----Original Message----- From: rlaw at nc.rr.com [mailto:rlaw at nc.rr.com] Sent: Tuesday, July 10, 2007 11:38 AM To: tz at lecserver.nci.nih.gov Subject: Re: Vietnam: Saigon is deprecated, should use capital Hanoi > As the term city is ambiguous, the standard is ambiguous and > inconsistent anyway. How can we put an end to the incessant disputation over time zone identifiers? If we go by metropolitan area populations, someone will say we should go by central city populations. If we use any criterion that chooses Hanoi, someone will say Ho Chi Minh City is more important; but others will argue that the capital city is always more important. We must bear in mind that these are only supposed to be identifiers. Conceptually, we could be using WT/QAF just as well as Europe/Rome. It was merely for the convenience of developers that mnemonic names were chosen. But it is the responsibility of a user interface, not of the tz database, to translate the time zone identifiers into user-friendly names. The volunteer maintainers of the tz database have plenty of work to do, just to keep it up to date. If their job description is expanded to include making sure that the definitions of cities are consistent, providing universally acceptable names and abbreviations for time zones, or enabling localization by giving the translations of city, country, and time zone names into an arbitrary number of languages, I believe that puts too much on their plate. Presumably the CLDR addresses localization issues. Whoever maintains the CLDR has undertaken responsibility for interpreting the identifiers into human-readable form. Identifiers should be stable, too. True, by using backward-compatibility links, we can minimize the disruption caused by changing an identifier. Still, any kind of change has its cost, and a lot of the cost is hidden. We don't know how many people have used "Europe/Rome" somewhere in their code or nomenclature or documentation, and would deem it necessary to change the string if the primary name of that time zone changed to "Europe/Milan". (Of course, some changes are unavoidable, when time zones split.) My suggestion would be to state boldly in the documentation, "Time zone identifiers are arbitrary. Although they look as if they have a geographic interpretation, there is no guarantee that they do, or will continue to in the future. They should not be displayed directly to end users." Then, if possible, there should be some discussion of how to display time zone information to users. If we get GIS files for time zone boundaries, that will be a big help. Maintaining the boundary files would fall within the purview of the tz mailing list. Gwillim Law From mark.davis at icu-project.org Tue Jul 10 23:45:53 2007 From: mark.davis at icu-project.org (Mark Davis) Date: Tue, 10 Jul 2007 16:45:53 -0700 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: <0165EECEBB4CF745ACF095E1176B03EA12C7FFE3@SUNCA-EXB-AV1.ticketmaster.corp> References: <0165EECEBB4CF745ACF095E1176B03EA12C7FFE3@SUNCA-EXB-AV1.ticketmaster.corp> Message-ID: <30b660a20707101645g4334f272k2444a65ecb0c10d3@mail.gmail.com> I agree with Gwillim Law; these are just identifiers. As far as I'm concerned, the best strategy would be 1. Never change remove or change what is in zone.tab. 2. Only add a new identifier to zone.tab if a zone splits. 3. For such a new identifier, pick the largest city in the new zone according to some reasonable authority (eg National Geographic Atlas of the World). Since it is just an identifier, don't worry about whether or not it includes metropolitan areas or how; don't worry about whether the authority is the best possible one or not. 4. Make sure that last field is unique, eg don't have America/United_States/San_Jose if you have America/Costa_Rica/San_Jose. If it would not be unique, choose a different identifier for zone.tab, or have some minor modification (San_Jose2) 5. Add aliases (links) where useful for clarification. Short of that, the current policies are reasonable, although it forces other parties (like CLDR) to impose additional measures for stability of identifiers. Mark On 7/10/07, Paul Schauble wrote: > > I suggested some time ago that zones should be named according to the > authority that declared the zone. This would often result in country > names or country name (subdivision). But it would also clearly identify > things like "Navajo Time" as such rather than lumping this in with > "Denver". > > I think this gives a more stable system that largest city. It completely > avoids the issues of what is a city. And it avoids changing zone names > when city population changes. > > ++PLS > > -----Original Message----- > From: rlaw at nc.rr.com [mailto:rlaw at nc.rr.com] > Sent: Tuesday, July 10, 2007 11:38 AM > To: tz at lecserver.nci.nih.gov > Subject: Re: Vietnam: Saigon is deprecated, should use capital Hanoi > > > As the term city is ambiguous, the standard is ambiguous and > > inconsistent anyway. > > How can we put an end to the incessant disputation over time zone > identifiers? If we go by metropolitan area populations, someone will > say we should go by central city populations. If we use any criterion > that chooses Hanoi, someone will say Ho Chi Minh City is more important; > but others will argue that the capital city is always more important. > > We must bear in mind that these are only supposed to be identifiers. > Conceptually, we could be using WT/QAF just as well as Europe/Rome. It > was merely for the convenience of developers that mnemonic names were > chosen. But it is the responsibility of a user interface, not of the tz > database, to translate the time zone identifiers into user-friendly > names. > > The volunteer maintainers of the tz database have plenty of work to do, > just to keep it up to date. If their job description is expanded to > include making sure that the definitions of cities are consistent, > providing universally acceptable names and abbreviations for time zones, > or enabling localization by giving the translations of city, country, > and time zone names into an arbitrary number of languages, I believe > that puts too much on their plate. > > Presumably the CLDR addresses localization issues. Whoever maintains > the CLDR has undertaken responsibility for interpreting the identifiers > into human-readable form. > > Identifiers should be stable, too. True, by using > backward-compatibility links, we can minimize the disruption caused by > changing an identifier. Still, any kind of change has its cost, and a > lot of the cost is hidden. We don't know how many people have used > "Europe/Rome" somewhere in their code or nomenclature or documentation, > and would deem it necessary to change the string if the primary name of > that time zone changed to "Europe/Milan". (Of course, some changes are > unavoidable, when time zones split.) > > My suggestion would be to state boldly in the documentation, "Time zone > identifiers are arbitrary. Although they look as if they have a > geographic interpretation, there is no guarantee that they do, or will > continue to in the future. They should not be displayed directly to end > users." Then, if possible, there should be some discussion of how to > display time zone information to users. If we get GIS files for time > zone boundaries, that will be a big help. Maintaining the boundary > files would fall within the purview of the tz mailing list. > > Gwillim Law > -- Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/tz/attachments/20070710/4b942b11/attachment.html From bernard.desruisseaux at oracle.com Wed Jul 11 01:40:16 2007 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Tue, 10 Jul 2007 21:40:16 -0400 Subject: FW: Time Zone mapping --> Windows ??? In-Reply-To: References: Message-ID: <46943500.6020407@oracle.com> Mapping from Windows Time Zone Names to Olson Time Zone Keys http://www.chronos-st.org/Windows-to-Olson.html Unicode CLDR Version 1.5-draft: Windows --> Tzid http://unicode.org/cldr/data/diff/supplemental/windows_tzid.html Olson, Arthur David (NIH/NCI) [E] wrote: > I'm forwarding this message from Boris Lang, who is not on the time zone mailing list. > > Those of you who are on the time zone mailing list should direct replies appropriately. > > --ado > > -----Original Message----- > From: BORIS LANG [mailto:BORIS.LANG at MEMO.IKEA.COM] > Sent: Tuesday, July 10, 2007 8:55 AM > To: tz at lecserver.nci.nih.gov > Subject: Time Zone mapping --> Windows ??? > > --- Received from IKEA4.BRLG +49 6122 5858276 07-07-10 14.56 -------------------------------------- > > Hi, > > we are working on the implementation of time zone information into an application using the tz database. TZ data names > will be our main type but we also need to do a mapping to the time zone names used in windows. > > i.e. Europe/Berlin (tzd) --> Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna (Windows) > > > The problem is that I can?t find a complete list that contains the mapping from tz database to windows. > > Can somebody please help us? Is there already such a list existing? > > Best regards > Boris Lang > > > ------ > IKEA IT Germany GmbH > Am Wandersmann 2-4 > 65719 Hofheim-Wallau > > Sitz M?nchen HR B 79392, Amtsgericht M?nchen > Gesch?ftsf?hrer: Manfred Godlewski, G?ran Sj?strand, Ola Troedsson > > ---- 07-07-10 14.56 ---- Sent to --------------------------------------------------------------------------------- > -> tz at elsie.nci.nih.gov From autarch at urth.org Wed Jul 11 04:21:06 2007 From: autarch at urth.org (Dave Rolsky) Date: Tue, 10 Jul 2007 23:21:06 -0500 (CDT) Subject: FW: Time Zone mapping --> Windows ??? In-Reply-To: <46943500.6020407@oracle.com> References: <46943500.6020407@oracle.com> Message-ID: On Tue, 10 Jul 2007, Bernard Desruisseaux wrote: > Mapping from Windows Time Zone Names to Olson Time Zone Keys > http://www.chronos-st.org/Windows-to-Olson.html Unfortunately, these names are localized in Windows, so this mapping only works for English language Windows versions. I'm using this mapping in a Perl module I wrote (DateTime::TimeZone - http://search.cpan.org/dist/DateTime-TimeZone/) and got a bug report from a user regarding this issue. -dave /*=================================================== VegGuide.Org www.BookIRead.com Your guide to all that's veg. My book blog ===================================================*/ From kre at munnari.OZ.AU Wed Jul 11 13:15:33 2007 From: kre at munnari.OZ.AU (Robert Elz) Date: Wed, 11 Jul 2007 20:15:33 +0700 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: <0165EECEBB4CF745ACF095E1176B03EA12C7FFE3@SUNCA-EXB-AV1.ticketmaster.corp> References: <0165EECEBB4CF745ACF095E1176B03EA12C7FFE3@SUNCA-EXB-AV1.ticketmaster.corp> Message-ID: <19132.1184159733@munnari.OZ.AU> Date: Tue, 10 Jul 2007 15:12:44 -0700 From: "Paul Schauble" Message-ID: <0165EECEBB4CF745ACF095E1176B03EA12C7FFE3 at SUNCA-EXB-AV1.ticketmaster.corp> | I suggested some time ago that zones should be named according to the | authority that declared the zone. Does that work in the US, where all zones are under the authority of the Dept of Transport (or something like that) - you'd still need additional names to determine just which of the multiple different zones they meant - and even then dealing with historical names would mean that you can't just use the names the relevant dept assign, as they don't usually bother to provide names for things which are no longer current, but we need them. Just stop arguing about this silly issue - it doesn't really matter what the zones are called. City names are a fairly good choice, as it is very unlikely that a single city doesn't have a single timezone history and rules. Further, the biggest city is a good choice, as it is unlikely that people aren't going to know if the local time is different than whatever is the biggest regional city. Definitions of cities don't need to be precise - nothing really important depends upon the results - we aren't specifying the time that applies in that city, just using its name as the label for a time zone (where any unique label would do just as well - which is why when the city that would normally be selected doesn't have a unique enough name, we just pick another.) A "city" is just what some outsider would consider to be that city, so as far as I'm concerned, if I arrive at Heathrowe (or Gatwick) I'm in London. On the other hand, if I'm in Essen, I'm in Essen, the city, Ruhrgebiet, or Rhein-Ruhr is a region name, not a city, so they're not really options for us to choose. Stability is not too much of an issue either, nothing depends upon "biggest" that's just a convenient way to (try to) pick cities without having these endless absurd arguments. That's why "most important" is never going to work - all that would ever do is cause arguments, never settle any. Once picked, we retain the same city name, even if something else becomes bigger - at least until it is clear that some other city is substantially larger and going to remain that way. Whether we should be using Rome or Milan in Italy, I'll leave to someone who understands Italian geography and politics - if it should be Milan, we can just fix it (and of course, keep Rome as an alias). That is, if everyone who knows enough to have an opinion on this (which certainly excludes me) agrees that Milan is substantially bigger than Rome, and that isn't likely to change. If the issue is debatable enough for anyone to argue (reasonably) about, then we should just stick with what we have. The same for Calcutta/Mumbai and Karachi/Lahor. We already had the Beijing/Shanghai discussion, and while it may alter in the future, things don't yet seem clear cut enough to make a change there. kre From Masayoshi.Okutsu at Sun.COM Wed Jul 11 15:03:38 2007 From: Masayoshi.Okutsu at Sun.COM (Masayoshi Okutsu) Date: Thu, 12 Jul 2007 00:03:38 +0900 Subject: FW: Time Zone mapping --> Windows ??? In-Reply-To: References: <46943500.6020407@oracle.com> Message-ID: <4694F14A.4020907@sun.com> On 7/11/2007 1:21 PM, Dave Rolsky wrote: > On Tue, 10 Jul 2007, Bernard Desruisseaux wrote: > >> Mapping from Windows Time Zone Names to Olson Time Zone Keys >> http://www.chronos-st.org/Windows-to-Olson.html > > Unfortunately, these names are localized in Windows, so this mapping > only works for English language Windows versions. I'm using this > mapping in a Perl module I wrote (DateTime::TimeZone - > http://search.cpan.org/dist/DateTime-TimeZone/) and got a bug report > from a user regarding this issue. In case you are tring to find out the tzid for the current Windows time zone... The time zone names from GetTimeZoneInformation() are localized. You'd need to find the "Time Zones" registry entry that matches the GetTimeZoneInformation() return value. Then, its registry key name can be used to look up a mapping table. However, different Windows versions use different key names. And some old localized Windows (NT/2000) have localized key names. In that case Java uses the mapID value which is not in Windows XP with a time zone patch and Vista. IIRC, key name "GMT" is used for different time zones in different Windows versions. It's a mess if you try to map Windows time zones to tzids... Masayoshi From tkpublic at timklein.fastmail.fm Wed Jul 11 23:15:36 2007 From: tkpublic at timklein.fastmail.fm (Tim Klein) Date: Wed, 11 Jul 2007 18:15:36 -0500 Subject: Is there a list of "current" time zones? In-Reply-To: References: Message-ID: Thank you, to those who helped me with this question! Especially big thanks to the ICU project folks (icu-project.org), whose "metazones" work got us most of the way to the data we needed. Tim From vuntz at gnome.org Thu Jul 12 14:09:19 2007 From: vuntz at gnome.org (Vincent Untz) Date: Thu, 12 Jul 2007 16:09:19 +0200 Subject: Localization of timezones from zone.tab In-Reply-To: References: Message-ID: <20070712140919.GP30640@vuntz.net> Le mardi 10 juillet 2007, ? 13:34 -0400, Andy Lipscomb a ?crit : > Currently, the main effort to localize time-zone information is in the Common Language Data Repository (I think that's what it's called, I know it's CLDR for initials), hosted at http://www.unicode.org/cldr; for each zone, there is the option to localize two names (DST and standard), the initials for those names, and the example city. Thanks for the pointer. I didn't know that CLDR contains this. That's cool :-) Vincent -- Les gens heureux ne sont pas press?s. From clive at demon.net Fri Jul 13 09:05:52 2007 From: clive at demon.net (Clive D.W. Feather) Date: Fri, 13 Jul 2007 10:05:52 +0100 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: <30b660a20707101645g4334f272k2444a65ecb0c10d3@mail.gmail.com> References: <0165EECEBB4CF745ACF095E1176B03EA12C7FFE3@SUNCA-EXB-AV1.ticketmaster.corp> <30b660a20707101645g4334f272k2444a65ecb0c10d3@mail.gmail.com> Message-ID: <20070713090552.GF21582@finch-staff-1.thus.net> Mark Davis said: > I agree with Gwillim Law; these are just identifiers. As far as I'm > concerned, the best strategy would be > > 1. Never change remove or change what is in zone.tab. > 2. Only add a new identifier to zone.tab if a zone splits. I would certainly agree with those. Stability is more important than always providing the name of the current largest city. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | From clive at demon.net Fri Jul 13 09:17:50 2007 From: clive at demon.net (Clive D.W. Feather) Date: Fri, 13 Jul 2007 10:17:50 +0100 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: References: Message-ID: <20070713091750.GG21582@finch-staff-1.thus.net> Claus F?rber said: >> Not if it's London as in the Greater London Authority (or, historically, >> the Greater London Council, the London County Council, etc.), as opposed >> to the City of London which has been only a small part of the geography >> and government of the greater city for centuries. > The GLA is a super-city authority, covering multiple cities such as the > City of London, the City of Westminster, etc. Well, that just proves my > point that the term "city" introduces ambiguity. The term "city" has at least three meanings within the UK: (1) [the legal definition] A local authority area granted city status by the crown. The LA may be a District, a Borough, or a Parish. (2) [the pub lawyer's definition] A conurbation containing a cathedral. (3) [colloquial] A large conurbation. London is a city under the second and third definitions, and a local authority area containing two cities under the first. But so what? Every country has its own concept of what a "city" is and how it differs from a town. The colloquial one is probably better *FOR THIS PURPOSE* than either of the other two. > It's simply inconsistent to treat Greater London as a "city", which is > made up of multiple municipalities like the City of London, Westminster, > etc., They aren't municipalities, they're boroughs. And Birmingham is equally split up into wards. So what? > It's also inconsistent to treat Greater London as a "city" and not > Greater Milan (7 million), which would be substantially larger than > Rome or Greater Rome (2.5 or 3.3 million). Does "Greater Milan" have a single governmental authority? -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | From kre at munnari.OZ.AU Fri Jul 13 13:59:11 2007 From: kre at munnari.OZ.AU (Robert Elz) Date: Fri, 13 Jul 2007 20:59:11 +0700 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: <20070713091750.GG21582@finch-staff-1.thus.net> References: <20070713091750.GG21582@finch-staff-1.thus.net> Message-ID: <16339.1184335151@munnari.OZ.AU> Date: Fri, 13 Jul 2007 10:17:50 +0100 From: "Clive D.W. Feather" Message-ID: <20070713091750.GG21582 at finch-staff-1.thus.net> | But so what? Every country has its own concept of what a "city" is and how | it differs from a town. Actually, for us, that distinction isn't relevant either. We use "city" to just mean "local population centre" - whether that's a village, town or "city" in some other nomenclature doesn't matter. All that matters is that it is a location where people live closely enough together that they're all going to set their clocks to the same time. (If some area that people might like to call a city, such as the Coolangatta/Tweed Heads on the Qld/NSW border in Aust, doesn't have the "same time" property, then it is useless for our purposes, and doesn't warrang further consideration, unless perhaps one or more of its time zones is uniquely used in that area) | Does "Greater Milan" have a single governmental authority? That doesn't matter either - the Sydney/Blacktown example would fail if that were the test. The local govt authority for Sydney covers a fairly small area, and while the population there during working hours is fairly high, not very many actually live there, there are plenty of municipalities (with their own local govt) that would have larger populations than the city of Sydney (according to municipal boundaries). Whether Blacktown is the biggest of them or not I have no idea, but it might be. But that's not the Sydney that almost anyone thinks of - even people who live in Blacktown would tell you that they're from Sydney if you ask them, not from Blacktown - not unless you ask "where in Sydney?". Sydney for our purposes includes all its suburbs, and perhaps even (these days) the Illawarra region (Wollongong etc) and maybe even Newcastle (if it doesn't it probably will within a few years). kre From eggert at CS.UCLA.EDU Wed Jul 18 07:26:17 2007 From: eggert at CS.UCLA.EDU (Paul Eggert) Date: Wed, 18 Jul 2007 00:26:17 -0700 Subject: FW: Does UTC+14 Still Exist? In-Reply-To: (Arthur David Olson's message of "Wed\, 27 Jun 2007 08\:20\:36 -0400") References: Message-ID: <87myxurx46.fsf@penguin.cs.ucla.edu> > From: Robert Chapin [mailto:tz at info-svc.com] > Sent: Tuesday, June 26, 2007 10:47 PM > > The latest CIA map doesn't have the UTC+14 time zone on it.. > > https://www.cia.gov/library/publications/the-world-factbook/reference_maps/pdf/time_zones.pdf The previous (2005) CIA map didn't either; see . Perhaps news travels slowly to the CIA? From eggert at CS.UCLA.EDU Wed Jul 18 07:37:28 2007 From: eggert at CS.UCLA.EDU (Paul Eggert) Date: Wed, 18 Jul 2007 00:37:28 -0700 Subject: Geographical boundaries for the continental US tz zones In-Reply-To: <4687DF3F.2080005@adobe.com> (Eric Muller's message of "Sun\, 01 Jul 2007 10\:07\:11 -0700") References: <465E634D.2080301@adobe.com> <4687DF3F.2080005@adobe.com> Message-ID: <87ir8irwlj.fsf@penguin.cs.ucla.edu> Eric Muller writes: > I have completed a first version of a map of the TZ timezones in the US. > It is available as a shapefile at . Thanks. Does the following HTML summarize it accurately?
  • A map of the TZ timezones in the US contains a shapefile of the tz regions in the US.
    • From eggert at CS.UCLA.EDU Wed Jul 18 07:41:28 2007 From: eggert at CS.UCLA.EDU (Paul Eggert) Date: Wed, 18 Jul 2007 00:41:28 -0700 Subject: Geographical boundaries for the continental US tz zones In-Reply-To: (Jesper Norgaard Welen's message of "Sun\, 01 Jul 2007 17\:32\:22 -0500") References: Message-ID: <87ejj6rwev.fsf@penguin.cs.ucla.edu> Jesper Norgaard Welen tried to send the following email to the list on July 1, but apparently didn't get through. I am enclosing it in the hopes that it does get through this time. From: Jesper Norgaard Welen [mailto:jnorgard at prodigy.net.mx] Sent: Domingo, 01 de Julio de 2007 16:15 To: 'tz at elsie.nci.nih.gov' Cc: 'emuller at adobe.com' Subject: RE: Geographical boundaries for the continental US tz zones Hello, Eric Muller I send my comments to your US timezone map directly to the TZ list since I think it could be of common interest in the list and also to urge members to send comments where appropriate. My newest map for World Time Explorer you can download from http://worldtimeexplorer.com/tztables.zip * Navajo/Hopi reservations There is an important Hopi population that you have not included around Latitude 36.14 Longitude -109.40 that I would recommend you to include (see WTE map) * Nevada on Idaho time The city Jackpot in Nevada (and several others like Owyhee and Mountain city) are on Idaho south time, or Denver time if you will. I have included it in a 25 km broad strip of northern Elko county, however just based on common sense when there were cities 12 km below the border that were on Denver time, and I would not expect their time to stop 100 meters outside the city boundary, but note that it is arbitrary, and quite possibly not quite 25 km. Jackpot itself is quite close to the border to Idaho. * Idaho county split (Idaho state) I have a northern and southern part of Idaho county, which I got from another timezone map (possibly Manifold map). This indicates that the southern part of Idaho county is on America/Boise time while the northern part is on America/Los_Angeles. Note that this is *not* documented in the tz database - I am still a bit ambivalent which one to believe. If you want pure tz database functionality, the timezone border should be a little further south. * Alaska I have the same doubts as you. However, I have implemented a solution, however arbitrary it is, seems much better than just putting Juneau for all of Alaska. The Nome area is small, while most of northwestern Alaska is set to Anchorage time. Then there is a Yakutat area and a Juneau area. They are all based on counties in this area. Comments are welcome. * America/Kentucky/Louisville This city belongs to Jefferson county of Kentucky, so I just assumed that this would comprise the Louisville timezone - however tz database needs to describe this - and include more counties if there are more. It just states the vague "part of Kentucky". * Sioux county North Dakota Tz database states "part of Sioux county" and that is exactly what you have included, splitting it around Latitude 46 Longitude -101.34. Where did you get shis from? I have included all Sioux county being on same time, but that most be wrong. * Cherry county Nebraska I see you have a different, more detailed split of Cherry county than mine. Where did you get this from? * Morgan county, Tennessee I recently discovered that this county is on CST/CDT, and included this in the western part of Tennesse. It's around Latitude 36.07 Longitude -84.56 * Alabama Note that (parts of) Chambers, Lee and Russell counties should be on America/New_York time, not on America/Chicago time. * Culberson county, Texas Note that the parts of this county including Nickel creek and Pine Springs are on America/Denver time. Regards, - Jesper N?rgaard Welen -----Original Message----- From: Eric Muller [mailto:emuller at adobe.com] Sent: Domingo, 01 de Julio de 2007 12:07 To: tz at lecserver.nci.nih.gov Subject: Re: Geographical boundaries for the continental US tz zones I have completed a first version of a map of the TZ timezones in the US. It is available as a shapefile at . Comments welcome, Eric. From eggert at CS.UCLA.EDU Wed Jul 18 07:46:19 2007 From: eggert at CS.UCLA.EDU (Paul Eggert) Date: Wed, 18 Jul 2007 00:46:19 -0700 Subject: TimeZones and international waters In-Reply-To: (Christina Lawrence's message of "Sun\, 1 Jul 2007 13\:38\:00 -0500") References: Message-ID: <87abturw6s.fsf@penguin.cs.ucla.edu> "Christina Lawrence" writes: > What distance from shore defines "the territorial waters of any nation"? > Is it nation specific, or an internationally recognized distance from > shore? Sorry, but (like anything involving lawyers :-) it's complicated. Please see for some details. I'll add that URL too, in my next proposed patch. From eggert at CS.UCLA.EDU Wed Jul 18 07:56:19 2007 From: eggert at CS.UCLA.EDU (Paul Eggert) Date: Wed, 18 Jul 2007 00:56:19 -0700 Subject: Daviess, Dubois, Knox, Martin and Pike counties jump thru 1 more hoop Message-ID: <87644irvq4.fsf@penguin.cs.ucla.edu> The DOT yesterday announced a proposed rule that would move the 132,000 residents of Daviess, Dubois, Knox, Martin and Pike counties in Indiana back to Eastern time, effective November 4 (when DST ends this year). The proposed rule has a 30-day public comment period, and then must be approved by the DOT to become final. See the AP article on this subject at . From rlaw at nc.rr.com Wed Jul 18 16:07:45 2007 From: rlaw at nc.rr.com (rlaw at nc.rr.com) Date: Wed, 18 Jul 2007 12:07:45 -0400 Subject: Geographical boundaries for the continental US tz zones Message-ID: ----- Original Message ----- From: Paul Eggert > I send my comments to your US timezone map directly to the TZ list > since I > think it could be of common interest in the list and also to urge > members to > send comments where appropriate. I've put all of my findings about the limits of U.S. time zones (past and present) online at http://www.statoids.com/tus.html. It's all verbal description. For example: > * Idaho county split (Idaho state) > I have a northern and southern part of Idaho county, which I got from > another timezone map (possibly Manifold map). This indicates that the > southern part of Idaho county is on America/Boise time while the > northernpart is on America/Los_Angeles. I have "Idaho county north of the Salmon River" on Pacific Time. > * Sioux county North Dakota > Tz database states "part of Sioux county" and that is exactly what > you have > included, splitting it around Latitude 46 Longitude -101.34. Where > did you > get shis from? I have included all Sioux county being on same time, > but that > most be wrong. I have "Sioux county west of ND route 31" on Mountain Time. Gwillim Law From hellosticky at gmail.com Fri Jul 20 20:36:29 2007 From: hellosticky at gmail.com (Kevin) Date: Fri, 20 Jul 2007 16:36:29 -0400 Subject: Olson tz database tests Message-ID: <6936856c0707201336m479b4476wf0768ad826151586@mail.gmail.com> Hi, is there an existing suite of tests (e.g. unit tests, regression tests, etc.) for the Olson time zone database (to ensure validity, completeness, etc.)? I'm more interested in the logic than the language, although I would prefer C/C++, C#, or Java. Thanks, Kevin From f.de.kruijf at hetnet.nl Sun Jul 22 19:37:53 2007 From: f.de.kruijf at hetnet.nl (Freek de Kruijf) Date: Sun, 22 Jul 2007 13:37:53 -0600 Subject: Timezone of America/Tegucigalpa is wrong Message-ID: <200707221337.54120.f.de.kruijf@hetnet.nl> L.S. The timezone of America/Tegucigalpa includes a Daylight Saving Time. This is wrong. See http://en.wikipedia.org/wiki/Honduras . It is only UTC-6. I can confirm this, while I am there. -- fr.gr. Freek de Kruijf From Susan.Johnson at kronos.com Mon Jul 23 12:37:44 2007 From: Susan.Johnson at kronos.com (Johnson, Susan) Date: Mon, 23 Jul 2007 08:37:44 -0400 Subject: More daylight savings in Australia In-Reply-To: <873b34r8v6.fsf@penguin.cs.ucla.edu> References: <873b34r8v6.fsf@penguin.cs.ucla.edu> Message-ID: <48DD08B024C1A84EA744B144A7ACFB41082AFFCD@exchg-j.KRONOS.COM> Folks, Do we have any official word on what will happen in Western/Southern Australia and when? My Australian office tells me that it now looks like South Australia, NSW, ACT, Victoria, and Tasmania DST changes will occur the first Sunday in April 2008 - instead of the first Sunday in October 2007. All changes are permanent except for South Australia, which will undergo a 'trial' change. --Sue Susan Johnson Manager, Customer Engineering Product Management Kronos Incorporated p: (978) 947-4342 f: (978) 367-5818 www.kronos.com Experts at Improving the Performance of People and Business? -----Original Message----- From: Paul Eggert [mailto:eggert at CS.UCLA.EDU] Sent: Friday, April 13, 2007 4:12 AM To: tz at lecserver.nci.nih.gov Subject: Re: More daylight savings in Australia "Eric Ulevik" writes: > http://www.news.com.au/story/0,23599,21549128-2,00.html Thanks for the heads-up. Today's Sydney Morning Herald reports that South Australia and the Northern Territory (!) may sign up later, but that Western Australia and Queensland will not be involved. Perhaps we should wait a bit to see who falls into line. Also, the SMH says only "it is believed" the dates are as you mentioned. http://www.smh.com.au/articles/2007/04/12/1175971265494.html This is currently listed as the #4 most-viewed article on the Sydney Morning Herald web site. A slow news day? -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 269.3.0/758 - Release Date: 4/12/2007 11:52 AM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.12/910 - Release Date: 7/21/2007 3:52 PM From olsona at dc37a.nci.nih.gov Mon Jul 23 13:37:08 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Mon, 23 Jul 2007 09:37:08 -0400 Subject: FW: Timezone of America/Tegucigalpa is wrong Message-ID: I'm forwarding this message from Freek de Kruijf, who was not on the time zone mailing list at the time it was sent. Freek has since been added. --ado -----Original Message----- From: Freek de Kruijf [mailto:f.de.kruijf at hetnet.nl] Sent: Sunday, July 22, 2007 3:38 To: tz at lecserver.nci.nih.gov Subject: Timezone of America/Tegucigalpa is wrong L.S. The timezone of America/Tegucigalpa includes a Daylight Saving Time. This is wrong. See http://en.wikipedia.org/wiki/Honduras . It is only UTC-6. I can confirm this, while I am there. -- fr.gr. Freek de Kruijf From olsona at dc37a.nci.nih.gov Mon Jul 23 13:38:09 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Mon, 23 Jul 2007 09:38:09 -0400 Subject: FW: More daylight savings in Australia Message-ID: I'm forwarding this message from Susan Johnson, who is on the time zone mailing list at a different address than the one shown below. --ado -----Original Message----- From: Johnson, Susan [mailto:Susan.Johnson at kronos.com] Sent: Monday, July 23, 2007 8:39 To: tz at lecserver.nci.nih.gov Subject: RE: More daylight savings in Australia Folks, Do we have any official word on what will happen in Western/Southern Australia and when? My Australian office tells me that it now looks like South Australia, NSW, ACT, Victoria, and Tasmania DST changes will occur the first Sunday in April 2008 - instead of the first Sunday in October 2007. All changes are permanent except for South Australia, which will undergo a 'trial' change. --Sue Susan Johnson Manager, Customer Engineering Product Management Kronos Incorporated p: (978) 947-4342 f: (978) 367-5818 www.kronos.com Experts at Improving the Performance of People and Business(tm) -----Original Message----- From: Paul Eggert [mailto:eggert at CS.UCLA.EDU] Sent: Friday, April 13, 2007 4:12 AM To: tz at lecserver.nci.nih.gov Subject: Re: More daylight savings in Australia "Eric Ulevik" writes: > http://www.news.com.au/story/0,23599,21549128-2,00.html Thanks for the heads-up. Today's Sydney Morning Herald reports that South Australia and the Northern Territory (!) may sign up later, but that Western Australia and Queensland will not be involved. Perhaps we should wait a bit to see who falls into line. Also, the SMH says only "it is believed" the dates are as you mentioned. http://www.smh.com.au/articles/2007/04/12/1175971265494.html This is currently listed as the #4 most-viewed article on the Sydney Morning Herald web site. A slow news day? -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 269.3.0/758 - Release Date: 4/12/2007 11:52 AM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.12/910 - Release Date: 7/21/2007 3:52 PM From olsona at dc37a.nci.nih.gov Mon Jul 23 15:34:10 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Mon, 23 Jul 2007 11:34:10 -0400 Subject: Olson tz database tests In-Reply-To: <6936856c0707201336m479b4476wf0768ad826151586@mail.gmail.com> References: <6936856c0707201336m479b4476wf0768ad826151586@mail.gmail.com> Message-ID: The only thing I've got is the shell script below (known as "zgress" locally). --ado #!/bin/sh # Accept the names of two time zone package source directories (A and B). # Do a "make install" from each directory to temporary directories. # Apply the created "zdump" programs to all the created binary data files: # the A zdump to the A data (yielding AA results) # the A zdump to the B data (yielding AB results) # the B zdump to the A data (yielding BA results) # the B zdump to the B data (yielding BB results) # Report on differences. O=`basename "$0"` case $# in 2) ;; *) echo "$O: usage is $O atzsourcedir btzsourcedir" 1>&2 exit 1 ;; esac T=/tmp/,zgress$$ trap 'rm -f -r $T*' 0 1 2 3 15 # Step 1: do "make"s for both the A and B versions for pass in a b do ( cd "$1"; make clean; make install TOPDIR=$T$pass ) || exit 1 shift done # Step 2: apply both the A and B zdumps to both the A and B data for prog in a b do for data in a b do zdump=$T$prog/etc/zdump zoneinfo=$T$data/etc/zoneinfo $zdump -v `find $zoneinfo ! -type d -print | sort` 2>&- | sed "s@$zoneinfo/@@" > $T$prog$data done done # Step 3: do comparisons ls -l $T[ab][ab] left=aa for right in ab ba bb do diff $T$left $T$right | sed "s/^/$left vs. $right:/" done From eggert at CS.UCLA.EDU Mon Jul 23 23:07:48 2007 From: eggert at CS.UCLA.EDU (Paul Eggert) Date: Mon, 23 Jul 2007 16:07:48 -0700 Subject: Timezone of America/Tegucigalpa is wrong In-Reply-To: (Arthur David Olson's message of "Mon\, 23 Jul 2007 09\:37\:08 -0400") References: Message-ID: <87tzrulnwb.fsf@penguin.cs.ucla.edu> > From: Freek de Kruijf [mailto:f.de.kruijf at hetnet.nl] > Sent: Sunday, July 22, 2007 3:38 > > The timezone of America/Tegucigalpa includes a Daylight Saving Time. > This is wrong. See http://en.wikipedia.org/wiki/Honduras . It is > only UTC-6. I can confirm this, while I am there. Thanks. No need to confirm it; the latest version of the tz database already has this. You can get it from . It reports that Honduras observed DST in 1987/1988 and in 2006 (only). From eggert at CS.UCLA.EDU Mon Jul 23 23:46:25 2007 From: eggert at CS.UCLA.EDU (Paul Eggert) Date: Mon, 23 Jul 2007 16:46:25 -0700 Subject: FW: More daylight savings in Australia In-Reply-To: (Arthur David Olson's message of "Mon\, 23 Jul 2007 09\:38\:09 -0400") References: Message-ID: <87ps2ilm3y.fsf@penguin.cs.ucla.edu> > From: Johnson, Susan [mailto:Susan.Johnson at kronos.com] > Sent: Monday, July 23, 2007 8:39 > > My Australian office tells me that it now looks like South Australia, > NSW, ACT, Victoria, and Tasmania DST changes will occur the first Sunday > in April 2008 - instead of the first Sunday in October 2007. All > changes are permanent except for South Australia, which will undergo a > 'trial' change. Yes, that matches my understanding as well. Here are some changes that I plan to put into my next proposed set. These aren't "official" yet (as if anything in tz were "official" :-) but should give you a heads-up. --- australasia 2007/05/07 14:46:15 2007.6 +++ australasia 2007/07/23 23:23:07 @@ -79,7 +79,7 @@ Zone Australia/Lindeman 9:55:56 - LMT 1 # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule AS 1971 1985 - Oct lastSun 2:00s 1:00 - Rule AS 1986 only - Oct 19 2:00s 1:00 - -Rule AS 1987 max - Oct lastSun 2:00s 1:00 - +Rule AS 1987 2007 - Oct lastSun 2:00s 1:00 - Rule AS 1972 only - Feb 27 2:00s 0 - Rule AS 1973 1985 - Mar Sun>=1 2:00s 0 - Rule AS 1986 1989 - Mar Sun>=15 2:00s 0 - @@ -90,7 +90,9 @@ Rule AS 1993 only - Mar Sun>=1 2:00s 0 - Rule AS 1994 only - Mar Sun>=18 2:00s 0 - Rule AS 1995 2005 - Mar lastSun 2:00s 0 - Rule AS 2006 only - Apr Sun>=1 2:00s 0 - -Rule AS 2007 max - Mar lastSun 2:00s 0 - +Rule AS 2007 only - Mar lastSun 2:00s 0 - +Rule AS 2008 max - Apr Sun>=1 2:00s 0 - +Rule AS 2008 max - Oct Sun>=1 2:00s 1:00 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Adelaide 9:14:20 - LMT 1895 Feb 9:00 - CST 1899 May @@ -121,7 +123,8 @@ Rule AT 1991 2005 - Mar lastSun 2:00s 0 Rule AT 2000 only - Aug lastSun 2:00s 1:00 - Rule AT 2001 max - Oct Sun>=1 2:00s 1:00 - Rule AT 2006 only - Apr Sun>=1 2:00s 0 - -Rule AT 2007 max - Mar lastSun 2:00s 0 - +Rule AT 2007 only - Mar lastSun 2:00s 0 - +Rule AT 2008 max - Apr Sun>=1 2:00s 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Hobart 9:49:16 - LMT 1895 Sep 10:00 - EST 1916 Oct 1 2:00 @@ -145,9 +148,11 @@ Rule AV 1988 1999 - Oct lastSun 2:00s 1: Rule AV 1991 1994 - Mar Sun>=1 2:00s 0 - Rule AV 1995 2005 - Mar lastSun 2:00s 0 - Rule AV 2000 only - Aug lastSun 2:00s 1:00 - -Rule AV 2001 max - Oct lastSun 2:00s 1:00 - +Rule AV 2001 2007 - Oct lastSun 2:00s 1:00 - Rule AV 2006 only - Apr Sun>=1 2:00s 0 - -Rule AV 2007 max - Mar lastSun 2:00s 0 - +Rule AV 2007 only - Mar lastSun 2:00s 0 - +Rule AV 2008 max - Apr Sun>=1 2:00s 0 - +Rule AV 2008 max - Oct Sun>=1 2:00s 1:00 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Melbourne 9:39:52 - LMT 1895 Feb 10:00 Aus EST 1971 @@ -166,9 +171,11 @@ Rule AN 1987 1999 - Oct lastSun 2:00s 1: Rule AN 1990 1995 - Mar Sun>=1 2:00s 0 - Rule AN 1996 2005 - Mar lastSun 2:00s 0 - Rule AN 2000 only - Aug lastSun 2:00s 1:00 - -Rule AN 2001 max - Oct lastSun 2:00s 1:00 - +Rule AN 2001 2007 - Oct lastSun 2:00s 1:00 - Rule AN 2006 only - Apr Sun>=1 2:00s 0 - -Rule AN 2007 max - Mar lastSun 2:00s 0 - +Rule AN 2007 only - Mar lastSun 2:00s 0 - +Rule AN 2008 max - Apr Sun>=1 2:00s 0 - +Rule AN 2008 max - Oct Sun>=1 2:00s 1:00 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Sydney 10:04:52 - LMT 1895 Feb 10:00 Aus EST 1971 @@ -191,9 +198,11 @@ Rule LH 1987 1999 - Oct lastSun 2:00 0:3 Rule LH 1990 1995 - Mar Sun>=1 2:00 0 - Rule LH 1996 2005 - Mar lastSun 2:00 0 - Rule LH 2000 only - Aug lastSun 2:00 0:30 - -Rule LH 2001 max - Oct lastSun 2:00 0:30 - +Rule LH 2001 2007 - Oct lastSun 2:00 0:30 - Rule LH 2006 only - Apr Sun>=1 2:00 0 - -Rule LH 2007 max - Mar lastSun 2:00 0 - +Rule LH 2007 only - Mar lastSun 2:00 0 - +Rule LH 2008 max - Apr Sun>=1 2:00 0 - +Rule LH 2008 max - Oct Sun>=1 2:00 0:30 - Zone Australia/Lord_Howe 10:36:20 - LMT 1895 Feb 10:00 - EST 1981 Mar 10:30 LH LHST From cppcraze at gmail.com Fri Jul 27 04:55:30 2007 From: cppcraze at gmail.com (Martin Dong) Date: Fri, 27 Jul 2007 12:55:30 +0800 Subject: How to support such capabilites based on current Olson Time Zone implementation Message-ID: Dear All in this maillist, We have been investigating the feasibility of migrating Olson Time Zone Database to our system. Given that our system is Linux-based, we can just use tzcode implementation or Glibc functions because Glibc has adopted Olson implementation to some extent. But according to our basic and existing requirements, I have met some problems that I think are hard for me: - How to get the local time of different region or city at the same time? The basic requirement is to display the local time of different region or city at the same time. After some study of Olson implementation, I knew function "localtime" will handle everything, parsing tzfile and doing the conversion from utc to local time. The correct local time can be gotten through a simple invocation to "localtime". But "localtime" assumes the Sytem Local Time Zone is set in environmental variable "TZ" or from the Standard TimeZone file "/etc/localtime" if "TZ" is not defined in the process. In this case, how can a caller get the local time of some city which is not the System Local Time Zone? It seems we must change "TZ" or the Standard TimeZone file before calling "localtime" to get another city's local time because "localtime" doesn't take such an argument that can let caller specify a time zone, which means "localtime" can return the local time related to either the System Local Time Zone or the time zone user specifies. Although I know there're so many applications which already integrates the Olson Database and they have realized my above requirement "display multiple local time at the same time", I don't know how they make it. - How to get the notification of DST status change as time elaspes? This problem is out of our another requirement that we need to inform other components in our system of the DST status change in various conditions, such as changing time may lead to DST change, changing local time zone may lead to DST change, and as time elapsing, etc. The former two behaviors are user-active ones, we can track the change easily, but the problem is the last one, it's the system automatic behavior, our of the control of user. In this case, the system needs some CALLBACK ability to capture this change and further broadcast it. For our system, there's an Alarm Server that can provide timer machinasm. We will parse our own time zone database and get the next nearest DST transition time and add it to Alarm Server, then when the timer is time out, Alarm Server will trigger a CALLBACK function to further process. But it seems Olson is lack of such capability. After thinking from another perpsective, if we can get the next nearest DST transition time through Olson Time Zone database, we can still utilize our current Alarm Server. But it's still a problem how to get the next nearest DST transition time through the current Olson implementation because all the implementation is hiden behind "localtime". In all the public functions, there's no such one which can support getting the DST transition time. I don't have any good idea in mind right now. Should I make some modification to Olson to add such capability, or other way i could go? I will very much appreciate if any of you can give me some hints about above problems. Thank you in advance. Best Regards, -Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/tz/attachments/20070727/145af57a/attachment.html From jmorrow at sendwordnow.com Fri Jul 27 06:28:40 2007 From: jmorrow at sendwordnow.com (John B. Morrow) Date: Fri, 27 Jul 2007 02:28:40 -0400 Subject: Does zic currently compile time zone abbreviations correctly? Message-ID: <8C509380F5C1E64686251D030FA286E0A1DE40@LATSVIVEX01.sendwordnow.local> In the process of extracting time zone information from the zoneinfo database, I noticed that the abbreviation pointer break for quite a few time zones including Europe/London, Asia/Dubai, and quite a few others. The problem seems to be in the compiled time zone files so I spent some time looking at zic. What seems to be happening is that zic uses some criteria to determine of the abbreviation (and other info for types) is used and won't write it if it thinks it isn't needed. The problem is that it doesn't adjust the indexes (tt_abbrind) that reference those abbreviations, so they'll point to bad data or empty strings. My quick (and admittedly heavy handed fix) was to force zic to write all of the abbreviations, whether they are necessary or not. If this really is a problem, it should probably be fixed at some point. Please note that the data in our fairly recently updated Linux server has abbreviations that don't seem to work. If I'm missing something or there is some other way more correct way to reference the abbreviations, please let me know. I'm using tt_abbrind as per the tzfile man page and the tzcode2007f.tar.gz sources. John Morrow -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/tz/attachments/20070727/95cb552c/attachment.html From olsona at dc37a.nci.nih.gov Fri Jul 27 15:20:33 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Fri, 27 Jul 2007 11:20:33 -0400 Subject: FW: Does zic currently compile time zone abbreviations correctly? Message-ID: I'm forwarding this message from John B. Morrow, who is not on the time zone mailing list. Those of you who are on the time zone mailing list should direct replies appropriately. --ado From: John B. Morrow [mailto:jmorrow at sendwordnow.com] Sent: Friday, July 27, 2007 2:29 AM To: tz at lecserver.nci.nih.gov Subject: Does zic currently compile time zone abbreviations correctly? In the process of extracting time zone information from the zoneinfo database, I noticed that the abbreviation pointer break for quite a few time zones including Europe/London, Asia/Dubai, and quite a few others.? The problem seems to be in the compiled time zone files so I spent some time looking at zic.? What seems to be happening is that zic uses some criteria to determine of the abbreviation (and other info for types) is used and won't write it if it thinks it isn't needed.? The problem is that it doesn't adjust the indexes (tt_abbrind) that reference those abbreviations, so they'll point to bad data or empty strings.? My quick (and admittedly heavy handed fix) was to force zic to write all of the abbreviations, whether they are necessary or not.? If this really is a problem, it should probably be fixed at some point.? Please note that the data in our fairly recently updated Linux server has abbreviations that don't seem to work. If I'm missing something or there is some other way more correct way to reference the abbreviations, please let me know.? I'm using tt_abbrind as per the tzfile man page and the tzcode2007f.tar.gz sources. John Morrow From olsona at dc37a.nci.nih.gov Fri Jul 27 15:29:03 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Fri, 27 Jul 2007 11:29:03 -0400 Subject: Does zic currently compile time zone abbreviations correctly? In-Reply-To: References: Message-ID: The typescript below seems to indicate that there's nothing amiss with Europe/London; do you get different results if you run "tzhead"? --ado Script started on Fri 27 Jul 2007 11:24:37 AM EDT lecserver$ cat tzhead.c #include "private.h" struct tzhead { char tzh_magic[4]; /* TZ_MAGIC */ char tzh_version[1]; /* '\0' or '2' as of 2005 */ char tzh_reserved[15]; /* reserved--must be zero */ char tzh_ttisgmtcnt[4]; /* coded number of trans. time flags */ char tzh_ttisstdcnt[4]; /* coded number of trans. time flags */ char tzh_leapcnt[4]; /* coded number of leap seconds */ char tzh_timecnt[4]; /* coded number of transition times */ char tzh_typecnt[4]; /* coded number of local time types */ char tzh_charcnt[4]; /* coded number of abbr. chars */ }; static char * progname; static long long detzcode64(codep) const char * const codep; { register long long result; register int i; result = (codep[0] & 0x80) ? ~0L : 0L; for (i = 0; i < 8; ++i) result = result * 256 + (codep[i] & 0xff); return result; } static long long detzcode(codep) const char * const codep; { register long result; register int i; result = (codep[0] & 0x80) ? ~0L : 0L; for (i = 0; i < 4; ++i) result = (result << 8) | (codep[i] & 0xff); return result; } static void wild2exit(cp, dp) { (void) fprintf(stderr, "%s: wild result %s %s\n", progname, cp, dp); exit(1); } static void handle(filename) char * filename; { FILE * fp; struct tzhead tzh; long long ll; char c; int i; int pass; long ttisgmtcnt; long ttisstdcnt; long leapcnt; long timecnt; long typecnt; long charcnt; char buf[8]; struct tm tm; fp = fopen(filename, "r"); if (fp == NULL) wild2exit("result opening", filename); for (pass = 1; pass <= 2; ++pass) { if (fread(&tzh, sizeof tzh, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tversion\t", filename); c = tzh.tzh_version[0]; if (isascii(c) && isprint(c)) (void) putchar(c); else (void) printf("\\%o", c); (void) putchar('\n'); ttisgmtcnt = detzcode(tzh.tzh_ttisgmtcnt); ttisstdcnt = detzcode(tzh.tzh_ttisstdcnt); leapcnt = detzcode(tzh.tzh_leapcnt); timecnt = detzcode(tzh.tzh_timecnt); typecnt = detzcode(tzh.tzh_typecnt); charcnt = detzcode(tzh.tzh_charcnt); (void) printf("%s\tttisgmtcnt\t%ld\n", filename, ttisgmtcnt); (void) printf("%s\tttisstdcnt\t%ld\n", filename, ttisstdcnt); (void) printf("%s\tleapcnt\t%ld\n", filename, leapcnt); (void) printf("%s\ttimecnt\t%ld\n", filename, timecnt); (void) printf("%s\ttypecnt\t%ld\n", filename, typecnt); (void) printf("%s\tcharcnt\t%ld\n", filename, charcnt); for (i = 0; i < timecnt; ++i) { if (fread(buf, pass * 4, 1, fp) != 1) wild2exit("result reading", filename); ll = (pass == 1) ? detzcode(buf) : detzcode64(buf); { time_t l; l = ll; tm = *gmtime(&l); } (void) printf("%s\ttime[%d]\t%lld\t%s", filename, i, ll, asctime(&tm)); } for (i = 0; i < timecnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\ttype[%d]\t%d\n", filename, i, buf[0]); } for (i = 0; i < typecnt; ++i) { long l; if (fread(buf, 4, 1, fp) != 1) wild2exit("result reading", filename); l = detzcode(buf); (void) printf("%s\ttype[%d].offset\t%ld\n", filename, i, l); if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\ttype[%d].isdst\t%ld\n", filename, i, buf[0]); if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\ttype[%d].abbrind\t%ld\n", filename, i, buf[0]); } for (i = 0; i < charcnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tabbr[%d]\t", filename, i); if (isascii(buf[0]) && isprint(buf[0])) (void) printf("%c", buf[0]); else if (buf[0] == '\0') (void) printf("\\0"); else (void) printf("\%03o", buf[0]); (void) printf("\n"); } for (i = 0; i < ttisstdcnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tisstd[%d]\t%d\n", filename, i, buf[0]); } for (i = 0; i < ttisgmtcnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tisgmt[%d]\t%d\n", filename, i, buf[0]); } if (tzh.tzh_version[0] != '2') break; } if (fclose(fp) != 0) { (void) fprintf(stderr, "%s: wild result closing %s\n", progname, filename); exit(1); } } int main(argc, argv) int argc; char * argv[]; { int i; progname = argv[0]; for (i = 1; i < argc; ++i) handle(argv[i]); exit(0); } lecserver$ make tzhead cc -DTZDIR=\"/usr/local/etc/zoneinfo\" tzhead.c -o tzhead lecserver$ tzhead tmp/etc/zoneinfo/Europe/London | grep abbr tmp/etc/zoneinfo/Europe/London type[0].abbrind 0 tmp/etc/zoneinfo/Europe/London type[1].abbrind 4 tmp/etc/zoneinfo/Europe/London type[2].abbrind 8 tmp/etc/zoneinfo/Europe/London type[3].abbrind 0 tmp/etc/zoneinfo/Europe/London type[4].abbrind 0 tmp/etc/zoneinfo/Europe/London type[5].abbrind 4 tmp/etc/zoneinfo/Europe/London type[6].abbrind 4 tmp/etc/zoneinfo/Europe/London abbr[0] B tmp/etc/zoneinfo/Europe/London abbr[1] S tmp/etc/zoneinfo/Europe/London abbr[2] T tmp/etc/zoneinfo/Europe/London abbr[3] \0 tmp/etc/zoneinfo/Europe/London abbr[4] G tmp/etc/zoneinfo/Europe/London abbr[5] M tmp/etc/zoneinfo/Europe/London abbr[6] T tmp/etc/zoneinfo/Europe/London abbr[7] \0 tmp/etc/zoneinfo/Europe/London abbr[8] B tmp/etc/zoneinfo/Europe/London abbr[9] D tmp/etc/zoneinfo/Europe/London abbr[10] S tmp/etc/zoneinfo/Europe/London abbr[11] T tmp/etc/zoneinfo/Europe/London abbr[12] \0 tmp/etc/zoneinfo/Europe/London type[0].abbrind 0 tmp/etc/zoneinfo/Europe/London type[1].abbrind 4 tmp/etc/zoneinfo/Europe/London type[2].abbrind 8 tmp/etc/zoneinfo/Europe/London type[3].abbrind 12 tmp/etc/zoneinfo/Europe/London type[4].abbrind 4 tmp/etc/zoneinfo/Europe/London type[5].abbrind 4 tmp/etc/zoneinfo/Europe/London type[6].abbrind 8 tmp/etc/zoneinfo/Europe/London type[7].abbrind 8 tmp/etc/zoneinfo/Europe/London abbr[0] L tmp/etc/zoneinfo/Europe/London abbr[1] M tmp/etc/zoneinfo/Europe/London abbr[2] T tmp/etc/zoneinfo/Europe/London abbr[3] \0 tmp/etc/zoneinfo/Europe/London abbr[4] B tmp/etc/zoneinfo/Europe/London abbr[5] S tmp/etc/zoneinfo/Europe/London abbr[6] T tmp/etc/zoneinfo/Europe/London abbr[7] \0 tmp/etc/zoneinfo/Europe/London abbr[8] G tmp/etc/zoneinfo/Europe/London abbr[9] M tmp/etc/zoneinfo/Europe/London abbr[10] T tmp/etc/zoneinfo/Europe/London abbr[11] \0 tmp/etc/zoneinfo/Europe/London abbr[12] B tmp/etc/zoneinfo/Europe/London abbr[13] D tmp/etc/zoneinfo/Europe/London abbr[14] S tmp/etc/zoneinfo/Europe/London abbr[15] T tmp/etc/zoneinfo/Europe/London abbr[16] \0 lecserver$ exit script done on Fri 27 Jul 2007 11:25:04 AM EDT From: John B. Morrow [mailto:jmorrow at sendwordnow.com] Sent: Friday, July 27, 2007 2:29 AM To: tz at lecserver.nci.nih.gov Subject: Does zic currently compile time zone abbreviations correctly? In the process of extracting time zone information from the zoneinfo database, I noticed that the abbreviation pointer break for quite a few time zones including Europe/London, Asia/Dubai, and quite a few others.? The problem seems to be in the compiled time zone files so I spent some time looking at zic.? What seems to be happening is that zic uses some criteria to determine of the abbreviation (and other info for types) is used and won't write it if it thinks it isn't needed.? The problem is that it doesn't adjust the indexes (tt_abbrind) that reference those abbreviations, so they'll point to bad data or empty strings.? My quick (and admittedly heavy handed fix) was to force zic to write all of the abbreviations, whether they are necessary or not.? If this really is a problem, it should probably be fixed at some point.? Please note that the data in our fairly recently updated Linux server has abbreviations that don't seem to work. If I'm missing something or there is some other way more correct way to reference the abbreviations, please let me know.? I'm using tt_abbrind as per the tzfile man page and the tzcode2007f.tar.gz sources. John Morrow From olsona at dc37a.nci.nih.gov Fri Jul 27 15:32:31 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Fri, 27 Jul 2007 11:32:31 -0400 Subject: FW: How to support such capabilites based on current Olson Time Zone implementation Message-ID: I'm forwarding this message from Martin Dong, who is not on the time zone mailing list. Those of you who are on the time zone mailing list should direct replies appropriately. --ado From: Martin Dong [mailto:cppcraze at gmail.com] Sent: Friday, July 27, 2007 12:56 AM To: tz at lecserver.nci.nih.gov Subject: How to support such capabilites based on current Olson Time Zone implementation Dear All in this maillist, ? We have been investigating the feasibility of migrating Olson Time Zone Database to our system. Given that our system is Linux-based, we can just use tzcode implementation or Glibc functions because Glibc has adopted Olson implementation to some extent. But according to our basic and?existing requirements, I have met some problems that I think are hard for me: * How to get the local time of different region or city at the same time? The basic requirement is to display the local time of different region or city at the same time. After some study of Olson implementation, I knew function "localtime" will handle everything, parsing tzfile and doing the conversion from utc to local time. The correct local?time can be gotten through a simple invocation to "localtime". But "localtime" assumes the Sytem Local Time Zone is set in environmental variable "TZ" or from the Standard TimeZone file "/etc/localtime" if "TZ" is not defined in the process. In this case, how can?a caller get the local?time of some city which is not the System Local Time Zone? It seems we must change "TZ" or the Standard TimeZone file before calling "localtime" to get another city's local time because "localtime" doesn't take such an argument that can let caller specify a time zone, which means "localtime" can return the local time related to either the System Local Time Zone or the time zone user specifies. ? Although I know there're so many applications?which already integrates the Olson Database and they have realized my?above requirement "display multiple local time at the same time", I don't know how they make it.? * How to get the notification of DST status change as time elaspes? This problem is out of our another requirement that we need to inform other components in our system of the DST status change in various conditions, such as changing time may lead to DST change, changing local time zone may lead to DST change, and as time elapsing, etc. The former two behaviors are user-active ones, we can track the change easily, but the problem is the last one, it's the system automatic behavior, our of the control of user. In this case, the system needs some CALLBACK ability to capture this change and further broadcast it. For our system, there's an Alarm Server that can provide timer machinasm. We will parse our own time zone database and get the next nearest DST transition time and add it to Alarm Server, then when the timer is time out, Alarm Server will trigger a CALLBACK function to further process. ? But it seems Olson is lack of such capability. After thinking from another perpsective, if we can get the next nearest DST transition time through Olson Time Zone database, we can still utilize our current Alarm Server. But it's still a problem how to get the next nearest DST transition time through the current Olson implementation because all the implementation is hiden behind "localtime". In all the public functions, there's no such one which can support getting the DST transition time. ? I don't have any good idea in mind right now. Should I make some modification to Olson to add such capability, or other way i could go? I will very much appreciate if any of you can give me some hints about above problems. Thank you in advance. ? Best Regards, ? -Martin From jmorrow at sendwordnow.com Fri Jul 27 16:18:58 2007 From: jmorrow at sendwordnow.com (John B. Morrow) Date: Fri, 27 Jul 2007 12:18:58 -0400 Subject: Does zic currently compile time zone abbreviations correctly? References: Message-ID: <8C509380F5C1E64686251D030FA286E0A1DF52@LATSVIVEX01.sendwordnow.local> This response and program was very helpful. Apparently I was missing the level of indirection that converted the type in the ttinfo into an abbrind to look up the abbreviation. For some time zones, that was fine and for others it wasn't. Now that I've added that additional level in, my program seems to be working correctly. Thank you for your quick response. John Morrow -----Original Message----- From: Olson, Arthur David (NIH/NCI) [E] [mailto:olsona at dc37a.nci.nih.gov] Sent: Friday, July 27, 2007 11:29 AM To: tz at elsie.nci.nih.gov Cc: John B. Morrow Subject: RE: Does zic currently compile time zone abbreviations correctly? The typescript below seems to indicate that there's nothing amiss with Europe/London; do you get different results if you run "tzhead"? --ado Script started on Fri 27 Jul 2007 11:24:37 AM EDT lecserver$ cat tzhead.c #include "private.h" struct tzhead { char tzh_magic[4]; /* TZ_MAGIC */ char tzh_version[1]; /* '\0' or '2' as of 2005 */ char tzh_reserved[15]; /* reserved--must be zero */ char tzh_ttisgmtcnt[4]; /* coded number of trans. time flags */ char tzh_ttisstdcnt[4]; /* coded number of trans. time flags */ char tzh_leapcnt[4]; /* coded number of leap seconds */ char tzh_timecnt[4]; /* coded number of transition times */ char tzh_typecnt[4]; /* coded number of local time types */ char tzh_charcnt[4]; /* coded number of abbr. chars */ }; static char * progname; static long long detzcode64(codep) const char * const codep; { register long long result; register int i; result = (codep[0] & 0x80) ? ~0L : 0L; for (i = 0; i < 8; ++i) result = result * 256 + (codep[i] & 0xff); return result; } static long long detzcode(codep) const char * const codep; { register long result; register int i; result = (codep[0] & 0x80) ? ~0L : 0L; for (i = 0; i < 4; ++i) result = (result << 8) | (codep[i] & 0xff); return result; } static void wild2exit(cp, dp) { (void) fprintf(stderr, "%s: wild result %s %s\n", progname, cp, dp); exit(1); } static void handle(filename) char * filename; { FILE * fp; struct tzhead tzh; long long ll; char c; int i; int pass; long ttisgmtcnt; long ttisstdcnt; long leapcnt; long timecnt; long typecnt; long charcnt; char buf[8]; struct tm tm; fp = fopen(filename, "r"); if (fp == NULL) wild2exit("result opening", filename); for (pass = 1; pass <= 2; ++pass) { if (fread(&tzh, sizeof tzh, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tversion\t", filename); c = tzh.tzh_version[0]; if (isascii(c) && isprint(c)) (void) putchar(c); else (void) printf("\\%o", c); (void) putchar('\n'); ttisgmtcnt = detzcode(tzh.tzh_ttisgmtcnt); ttisstdcnt = detzcode(tzh.tzh_ttisstdcnt); leapcnt = detzcode(tzh.tzh_leapcnt); timecnt = detzcode(tzh.tzh_timecnt); typecnt = detzcode(tzh.tzh_typecnt); charcnt = detzcode(tzh.tzh_charcnt); (void) printf("%s\tttisgmtcnt\t%ld\n", filename, ttisgmtcnt); (void) printf("%s\tttisstdcnt\t%ld\n", filename, ttisstdcnt); (void) printf("%s\tleapcnt\t%ld\n", filename, leapcnt); (void) printf("%s\ttimecnt\t%ld\n", filename, timecnt); (void) printf("%s\ttypecnt\t%ld\n", filename, typecnt); (void) printf("%s\tcharcnt\t%ld\n", filename, charcnt); for (i = 0; i < timecnt; ++i) { if (fread(buf, pass * 4, 1, fp) != 1) wild2exit("result reading", filename); ll = (pass == 1) ? detzcode(buf) : detzcode64(buf); { time_t l; l = ll; tm = *gmtime(&l); } (void) printf("%s\ttime[%d]\t%lld\t%s", filename, i, ll, asctime(&tm)); } for (i = 0; i < timecnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\ttype[%d]\t%d\n", filename, i, buf[0]); } for (i = 0; i < typecnt; ++i) { long l; if (fread(buf, 4, 1, fp) != 1) wild2exit("result reading", filename); l = detzcode(buf); (void) printf("%s\ttype[%d].offset\t%ld\n", filename, i, l); if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\ttype[%d].isdst\t%ld\n", filename, i, buf[0]); if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\ttype[%d].abbrind\t%ld\n", filename, i, buf[0]); } for (i = 0; i < charcnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tabbr[%d]\t", filename, i); if (isascii(buf[0]) && isprint(buf[0])) (void) printf("%c", buf[0]); else if (buf[0] == '\0') (void) printf("\\0"); else (void) printf("\%03o", buf[0]); (void) printf("\n"); } for (i = 0; i < ttisstdcnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tisstd[%d]\t%d\n", filename, i, buf[0]); } for (i = 0; i < ttisgmtcnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tisgmt[%d]\t%d\n", filename, i, buf[0]); } if (tzh.tzh_version[0] != '2') break; } if (fclose(fp) != 0) { (void) fprintf(stderr, "%s: wild result closing %s\n", progname, filename); exit(1); } } int main(argc, argv) int argc; char * argv[]; { int i; progname = argv[0]; for (i = 1; i < argc; ++i) handle(argv[i]); exit(0); } lecserver$ make tzhead cc -DTZDIR=\"/usr/local/etc/zoneinfo\" tzhead.c -o tzhead lecserver$ tzhead tmp/etc/zoneinfo/Europe/London | grep abbr tmp/etc/zoneinfo/Europe/London type[0].abbrind 0 tmp/etc/zoneinfo/Europe/London type[1].abbrind 4 tmp/etc/zoneinfo/Europe/London type[2].abbrind 8 tmp/etc/zoneinfo/Europe/London type[3].abbrind 0 tmp/etc/zoneinfo/Europe/London type[4].abbrind 0 tmp/etc/zoneinfo/Europe/London type[5].abbrind 4 tmp/etc/zoneinfo/Europe/London type[6].abbrind 4 tmp/etc/zoneinfo/Europe/London abbr[0] B tmp/etc/zoneinfo/Europe/London abbr[1] S tmp/etc/zoneinfo/Europe/London abbr[2] T tmp/etc/zoneinfo/Europe/London abbr[3] \0 tmp/etc/zoneinfo/Europe/London abbr[4] G tmp/etc/zoneinfo/Europe/London abbr[5] M tmp/etc/zoneinfo/Europe/London abbr[6] T tmp/etc/zoneinfo/Europe/London abbr[7] \0 tmp/etc/zoneinfo/Europe/London abbr[8] B tmp/etc/zoneinfo/Europe/London abbr[9] D tmp/etc/zoneinfo/Europe/London abbr[10] S tmp/etc/zoneinfo/Europe/London abbr[11] T tmp/etc/zoneinfo/Europe/London abbr[12] \0 tmp/etc/zoneinfo/Europe/London type[0].abbrind 0 tmp/etc/zoneinfo/Europe/London type[1].abbrind 4 tmp/etc/zoneinfo/Europe/London type[2].abbrind 8 tmp/etc/zoneinfo/Europe/London type[3].abbrind 12 tmp/etc/zoneinfo/Europe/London type[4].abbrind 4 tmp/etc/zoneinfo/Europe/London type[5].abbrind 4 tmp/etc/zoneinfo/Europe/London type[6].abbrind 8 tmp/etc/zoneinfo/Europe/London type[7].abbrind 8 tmp/etc/zoneinfo/Europe/London abbr[0] L tmp/etc/zoneinfo/Europe/London abbr[1] M tmp/etc/zoneinfo/Europe/London abbr[2] T tmp/etc/zoneinfo/Europe/London abbr[3] \0 tmp/etc/zoneinfo/Europe/London abbr[4] B tmp/etc/zoneinfo/Europe/London abbr[5] S tmp/etc/zoneinfo/Europe/London abbr[6] T tmp/etc/zoneinfo/Europe/London abbr[7] \0 tmp/etc/zoneinfo/Europe/London abbr[8] G tmp/etc/zoneinfo/Europe/London abbr[9] M tmp/etc/zoneinfo/Europe/London abbr[10] T tmp/etc/zoneinfo/Europe/London abbr[11] \0 tmp/etc/zoneinfo/Europe/London abbr[12] B tmp/etc/zoneinfo/Europe/London abbr[13] D tmp/etc/zoneinfo/Europe/London abbr[14] S tmp/etc/zoneinfo/Europe/London abbr[15] T tmp/etc/zoneinfo/Europe/London abbr[16] \0 lecserver$ exit script done on Fri 27 Jul 2007 11:25:04 AM EDT From: John B. Morrow [mailto:jmorrow at sendwordnow.com] Sent: Friday, July 27, 2007 2:29 AM To: tz at lecserver.nci.nih.gov Subject: Does zic currently compile time zone abbreviations correctly? In the process of extracting time zone information from the zoneinfo database, I noticed that the abbreviation pointer break for quite a few time zones including Europe/London, Asia/Dubai, and quite a few others.? The problem seems to be in the compiled time zone files so I spent some time looking at zic.? What seems to be happening is that zic uses some criteria to determine of the abbreviation (and other info for types) is used and won't write it if it thinks it isn't needed.? The problem is that it doesn't adjust the indexes (tt_abbrind) that reference those abbreviations, so they'll point to bad data or empty strings.? My quick (and admittedly heavy handed fix) was to force zic to write all of the abbreviations, whether they are necessary or not.? If this really is a problem, it should probably be fixed at some point.? Please note that the data in our fairly recently updated Linux server has abbreviations that don't seem to work. If I'm missing something or there is some other way more correct way to reference the abbreviations, please let me know.? I'm using tt_abbrind as per the tzfile man page and the tzcode2007f.tar.gz sources. John Morrow From markus.icu at gmail.com Fri Jul 27 18:38:00 2007 From: markus.icu at gmail.com (Markus Scherer) Date: Fri, 27 Jul 2007 11:38:00 -0700 Subject: FW: How to support such capabilites based on current Olson Time Zone implementation In-Reply-To: References: Message-ID: <6bb028490707271138x31eaae4es8d2cac06354bd4b6@mail.gmail.com> Dear Martin, For at least the first requirement, you might want to try other time zone support libraries listed on this list's homepage [1], for example ICU [2]. You could also send an email to the icu-support mailing list [3] to see if your second can be provided for. [1] http://www.twinsun.com/tz/tz-link.htm [2] http://icu-project.org/ [3] http://icu-project.org/contacts.html Best regards, markus From markus.icu at gmail.com Fri Jul 27 18:51:45 2007 From: markus.icu at gmail.com (Markus Scherer) Date: Fri, 27 Jul 2007 11:51:45 -0700 Subject: please update ICU homepage URL on http://www.twinsun.com/tz/tz-link.htm Message-ID: <6bb028490707271151g1f33a59k9a5d569d9e29fe26@mail.gmail.com> Dear TZ DB maintainers, Please update the ICU homepage URL on http://www.twinsun.com/tz/tz-link.htm from http://www-306.ibm.com/software/globalization/icu/ to http://icu-project.org/ Thanks and best regards, markus From yoshito_umaoka at us.ibm.com Fri Jul 27 19:00:49 2007 From: yoshito_umaoka at us.ibm.com (yoshito_umaoka at us.ibm.com) Date: Fri, 27 Jul 2007 15:00:49 -0400 Subject: FW: How to support such capabilites based on current Olson Time Zone implementation In-Reply-To: <6bb028490707271138x31eaae4es8d2cac06354bd4b6@mail.gmail.com> Message-ID: For the second requirement "getting the next nearest DST transition time", next version of ICU (ICU 3.8) will provide the API. -Yoshito "Markus Scherer" wrote on 07/27/2007 02:38:00 PM: > Dear Martin, > > For at least the first requirement, you might want to try other time > zone support libraries listed on this list's homepage [1], for example > ICU [2]. You could also send an email to the icu-support mailing list > [3] to see if your second can be provided for. > > [1] http://www.twinsun.com/tz/tz-link.htm > [2] http://icu-project.org/ > [3] http://icu-project.org/contacts.html > > Best regards, > markus From olsona at dc37a.nci.nih.gov Fri Jul 27 19:15:56 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Fri, 27 Jul 2007 15:15:56 -0400 Subject: FW: Does zic currently compile time zone abbreviations correctly? Message-ID: I'm forwarding this message from John Morrow, who is not on the time zone mailing list. Those of you who are on the time zone mailing list should direct replies appropriately. --ado -----Original Message----- From: John B. Morrow [mailto:jmorrow at sendwordnow.com] Sent: Friday, July 27, 2007 12:19 PM To: Olson, Arthur David (NIH/NCI) [E]; tz at lecserver.nci.nih.gov Subject: RE: Does zic currently compile time zone abbreviations correctly? This response and program was very helpful. Apparently I was missing the level of indirection that converted the type in the ttinfo into an abbrind to look up the abbreviation. For some time zones, that was fine and for others it wasn't. Now that I've added that additional level in, my program seems to be working correctly. Thank you for your quick response. John Morrow -----Original Message----- From: Olson, Arthur David (NIH/NCI) [E] [mailto:olsona at dc37a.nci.nih.gov] Sent: Friday, July 27, 2007 11:29 AM To: tz at elsie.nci.nih.gov Cc: John B. Morrow Subject: RE: Does zic currently compile time zone abbreviations correctly? The typescript below seems to indicate that there's nothing amiss with Europe/London; do you get different results if you run "tzhead"? --ado Script started on Fri 27 Jul 2007 11:24:37 AM EDT lecserver$ cat tzhead.c #include "private.h" struct tzhead { char tzh_magic[4]; /* TZ_MAGIC */ char tzh_version[1]; /* '\0' or '2' as of 2005 */ char tzh_reserved[15]; /* reserved--must be zero */ char tzh_ttisgmtcnt[4]; /* coded number of trans. time flags */ char tzh_ttisstdcnt[4]; /* coded number of trans. time flags */ char tzh_leapcnt[4]; /* coded number of leap seconds */ char tzh_timecnt[4]; /* coded number of transition times */ char tzh_typecnt[4]; /* coded number of local time types */ char tzh_charcnt[4]; /* coded number of abbr. chars */ }; static char * progname; static long long detzcode64(codep) const char * const codep; { register long long result; register int i; result = (codep[0] & 0x80) ? ~0L : 0L; for (i = 0; i < 8; ++i) result = result * 256 + (codep[i] & 0xff); return result; } static long long detzcode(codep) const char * const codep; { register long result; register int i; result = (codep[0] & 0x80) ? ~0L : 0L; for (i = 0; i < 4; ++i) result = (result << 8) | (codep[i] & 0xff); return result; } static void wild2exit(cp, dp) { (void) fprintf(stderr, "%s: wild result %s %s\n", progname, cp, dp); exit(1); } static void handle(filename) char * filename; { FILE * fp; struct tzhead tzh; long long ll; char c; int i; int pass; long ttisgmtcnt; long ttisstdcnt; long leapcnt; long timecnt; long typecnt; long charcnt; char buf[8]; struct tm tm; fp = fopen(filename, "r"); if (fp == NULL) wild2exit("result opening", filename); for (pass = 1; pass <= 2; ++pass) { if (fread(&tzh, sizeof tzh, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tversion\t", filename); c = tzh.tzh_version[0]; if (isascii(c) && isprint(c)) (void) putchar(c); else (void) printf("\\%o", c); (void) putchar('\n'); ttisgmtcnt = detzcode(tzh.tzh_ttisgmtcnt); ttisstdcnt = detzcode(tzh.tzh_ttisstdcnt); leapcnt = detzcode(tzh.tzh_leapcnt); timecnt = detzcode(tzh.tzh_timecnt); typecnt = detzcode(tzh.tzh_typecnt); charcnt = detzcode(tzh.tzh_charcnt); (void) printf("%s\tttisgmtcnt\t%ld\n", filename, ttisgmtcnt); (void) printf("%s\tttisstdcnt\t%ld\n", filename, ttisstdcnt); (void) printf("%s\tleapcnt\t%ld\n", filename, leapcnt); (void) printf("%s\ttimecnt\t%ld\n", filename, timecnt); (void) printf("%s\ttypecnt\t%ld\n", filename, typecnt); (void) printf("%s\tcharcnt\t%ld\n", filename, charcnt); for (i = 0; i < timecnt; ++i) { if (fread(buf, pass * 4, 1, fp) != 1) wild2exit("result reading", filename); ll = (pass == 1) ? detzcode(buf) : detzcode64(buf); { time_t l; l = ll; tm = *gmtime(&l); } (void) printf("%s\ttime[%d]\t%lld\t%s", filename, i, ll, asctime(&tm)); } for (i = 0; i < timecnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\ttype[%d]\t%d\n", filename, i, buf[0]); } for (i = 0; i < typecnt; ++i) { long l; if (fread(buf, 4, 1, fp) != 1) wild2exit("result reading", filename); l = detzcode(buf); (void) printf("%s\ttype[%d].offset\t%ld\n", filename, i, l); if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\ttype[%d].isdst\t%ld\n", filename, i, buf[0]); if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\ttype[%d].abbrind\t%ld\n", filename, i, buf[0]); } for (i = 0; i < charcnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tabbr[%d]\t", filename, i); if (isascii(buf[0]) && isprint(buf[0])) (void) printf("%c", buf[0]); else if (buf[0] == '\0') (void) printf("\\0"); else (void) printf("\%03o", buf[0]); (void) printf("\n"); } for (i = 0; i < ttisstdcnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tisstd[%d]\t%d\n", filename, i, buf[0]); } for (i = 0; i < ttisgmtcnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tisgmt[%d]\t%d\n", filename, i, buf[0]); } if (tzh.tzh_version[0] != '2') break; } if (fclose(fp) != 0) { (void) fprintf(stderr, "%s: wild result closing %s\n", progname, filename); exit(1); } } int main(argc, argv) int argc; char * argv[]; { int i; progname = argv[0]; for (i = 1; i < argc; ++i) handle(argv[i]); exit(0); } lecserver$ make tzhead cc -DTZDIR=\"/usr/local/etc/zoneinfo\" tzhead.c -o tzhead lecserver$ tzhead tmp/etc/zoneinfo/Europe/London | grep abbr tmp/etc/zoneinfo/Europe/London type[0].abbrind 0 tmp/etc/zoneinfo/Europe/London type[1].abbrind 4 tmp/etc/zoneinfo/Europe/London type[2].abbrind 8 tmp/etc/zoneinfo/Europe/London type[3].abbrind 0 tmp/etc/zoneinfo/Europe/London type[4].abbrind 0 tmp/etc/zoneinfo/Europe/London type[5].abbrind 4 tmp/etc/zoneinfo/Europe/London type[6].abbrind 4 tmp/etc/zoneinfo/Europe/London abbr[0] B tmp/etc/zoneinfo/Europe/London abbr[1] S tmp/etc/zoneinfo/Europe/London abbr[2] T tmp/etc/zoneinfo/Europe/London abbr[3] \0 tmp/etc/zoneinfo/Europe/London abbr[4] G tmp/etc/zoneinfo/Europe/London abbr[5] M tmp/etc/zoneinfo/Europe/London abbr[6] T tmp/etc/zoneinfo/Europe/London abbr[7] \0 tmp/etc/zoneinfo/Europe/London abbr[8] B tmp/etc/zoneinfo/Europe/London abbr[9] D tmp/etc/zoneinfo/Europe/London abbr[10] S tmp/etc/zoneinfo/Europe/London abbr[11] T tmp/etc/zoneinfo/Europe/London abbr[12] \0 tmp/etc/zoneinfo/Europe/London type[0].abbrind 0 tmp/etc/zoneinfo/Europe/London type[1].abbrind 4 tmp/etc/zoneinfo/Europe/London type[2].abbrind 8 tmp/etc/zoneinfo/Europe/London type[3].abbrind 12 tmp/etc/zoneinfo/Europe/London type[4].abbrind 4 tmp/etc/zoneinfo/Europe/London type[5].abbrind 4 tmp/etc/zoneinfo/Europe/London type[6].abbrind 8 tmp/etc/zoneinfo/Europe/London type[7].abbrind 8 tmp/etc/zoneinfo/Europe/London abbr[0] L tmp/etc/zoneinfo/Europe/London abbr[1] M tmp/etc/zoneinfo/Europe/London abbr[2] T tmp/etc/zoneinfo/Europe/London abbr[3] \0 tmp/etc/zoneinfo/Europe/London abbr[4] B tmp/etc/zoneinfo/Europe/London abbr[5] S tmp/etc/zoneinfo/Europe/London abbr[6] T tmp/etc/zoneinfo/Europe/London abbr[7] \0 tmp/etc/zoneinfo/Europe/London abbr[8] G tmp/etc/zoneinfo/Europe/London abbr[9] M tmp/etc/zoneinfo/Europe/London abbr[10] T tmp/etc/zoneinfo/Europe/London abbr[11] \0 tmp/etc/zoneinfo/Europe/London abbr[12] B tmp/etc/zoneinfo/Europe/London abbr[13] D tmp/etc/zoneinfo/Europe/London abbr[14] S tmp/etc/zoneinfo/Europe/London abbr[15] T tmp/etc/zoneinfo/Europe/London abbr[16] \0 lecserver$ exit script done on Fri 27 Jul 2007 11:25:04 AM EDT From: John B. Morrow [mailto:jmorrow at sendwordnow.com] Sent: Friday, July 27, 2007 2:29 AM To: tz at lecserver.nci.nih.gov Subject: Does zic currently compile time zone abbreviations correctly? In the process of extracting time zone information from the zoneinfo database, I noticed that the abbreviation pointer break for quite a few time zones including Europe/London, Asia/Dubai, and quite a few others.? The problem seems to be in the compiled time zone files so I spent some time looking at zic.? What seems to be happening is that zic uses some criteria to determine of the abbreviation (and other info for types) is used and won't write it if it thinks it isn't needed.? The problem is that it doesn't adjust the indexes (tt_abbrind) that reference those abbreviations, so they'll point to bad data or empty strings.? My quick (and admittedly heavy handed fix) was to force zic to write all of the abbreviations, whether they are necessary or not.? If this really is a problem, it should probably be fixed at some point.? Please note that the data in our fairly recently updated Linux server has abbreviations that don't seem to work. If I'm missing something or there is some other way more correct way to reference the abbreviations, please let me know.? I'm using tt_abbrind as per the tzfile man page and the tzcode2007f.tar.gz sources. John Morrow From cppcraze at gmail.com Mon Jul 30 09:21:51 2007 From: cppcraze at gmail.com (Martin Dong) Date: Mon, 30 Jul 2007 17:21:51 +0800 Subject: FW: How to support such capabilites based on current Olson Time Zone implementation In-Reply-To: References: <6bb028490707271138x31eaae4es8d2cac06354bd4b6@mail.gmail.com> Message-ID: Dear Markus and Yoshito, Thanks for leading me to ICU project, which is really a full-featured library for internationalization. I feel it's more appropriate to consider using it from the very initial system design. However our system has already had its own internationalization mechanism, now we only want to utilize Olson Time Zone database. We need a light-weight solution but I think ICU is too heavy for us. Actually tzcode is a light-weight implementation, if I can make some change based on it to support what I want, I think it's enough. Dear Olson, I want to know more about tzfile in binary form. Is there any other detailed description? I feel it's a little bit hard to get it understood just through the tzcode (because the comments are vrey few:-). Btw, for now can any new functionality be added into tzcode implementation? Or another question, if my change can meet my requirements and it goes into our system, does it need to go into Olson tzcode? Sincerely, -Martin On 7/28/07, yoshito_umaoka at us.ibm.com wrote: > > For the second requirement "getting the next nearest DST transition time", > next version of ICU (ICU 3.8) will provide the API. > > -Yoshito > > "Markus Scherer" wrote on 07/27/2007 02:38:00 PM: > > > Dear Martin, > > > > For at least the first requirement, you might want to try other time > > zone support libraries listed on this list's homepage [1], for example > > ICU [2]. You could also send an email to the icu-support mailing list > > [3] to see if your second can be provided for. > > > > [1] http://www.twinsun.com/tz/tz-link.htm > > [2] http://icu-project.org/ > > [3] http://icu-project.org/contacts.html > > > > Best regards, > > markus > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/tz/attachments/20070730/065ad081/attachment.html From olsona at dc37a.nci.nih.gov Mon Jul 30 13:29:03 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Mon, 30 Jul 2007 09:29:03 -0400 Subject: FW: How to support such capabilites based on current Olson Time Zone implementation Message-ID: I'm forwarding this message from Martin Doug, who is not on the time zone mailing list. Those of you who are on the time zone mailing list should direct replies appropriately. --ado From: Martin Dong [mailto:cppcraze at gmail.com] Sent: Monday, July 30, 2007 5:22 To: markus.icu at gmail.com; yoshito_umaoka at us.ibm.com Cc: tz at lecserver.nci.nih.gov Subject: Re: FW: How to support such capabilites based on current Olson Time Zone implementation Dear Markus and Yoshito, ? Thanks for leading me to ICU project, which is really a full-featured library for internationalization. I feel it's more appropriate to consider using it from the very?initial system design. However our system has already had its own internationalization mechanism, now we only want to utilize Olson Time Zone database.?We need a light-weight solution but I think ICU is too heavy for us. ? Actually tzcode is a light-weight implementation, if I can make some change based on it to support what I want, I think it's enough. ? Dear Olson, ? I want to know more about tzfile in binary form. Is there any other detailed description? I feel it's?a little bit hard to get it understood just through the tzcode (because the comments are vrey few:-). ? Btw,?for now can any new functionality be added into tzcode implementation? Or another question, if my change can meet my requirements and it goes into our system, does it need to go into Olson tzcode? ? Sincerely, -Martin ? On 7/28/07, yoshito_umaoka at us.ibm.com wrote: For the second requirement "getting the next nearest DST transition time", next version of ICU (ICU 3.8) will provide the API. -Yoshito "Markus Scherer" wrote on 07/27/2007 02:38:00 PM: > Dear Martin, > > For at least the first requirement, you might want to try other time > zone support libraries listed on this list's homepage [1], for example > ICU [2]. You could also send an email to the icu-support mailing list > [3] to see if your second can be provided for. > > [1] http://www.twinsun.com/tz/tz-link.htm > [2] http://icu-project.org/ > [3] http://icu-project.org/contacts.html > > Best regards, > markus From hellosticky at gmail.com Sun Jul 1 14:26:27 2007 From: hellosticky at gmail.com (Kevin) Date: Sun, 1 Jul 2007 10:26:27 -0400 Subject: FW: Implementation of zoneinfo (Olson, tz) database in .NET c-sharp csharp In-Reply-To: <87bqf9tdlu.fsf@penguin.cs.ucla.edu> References: <87bqf9tdlu.fsf@penguin.cs.ucla.edu> Message-ID: <6936856c0707010726k7c48f255t3f7c499de89222ca@mail.gmail.com> Hi tzlist, I created this PublicDomain package as well as the tz database integration. I had been meaning to notify the list, but the current support is quite experimental, so I was waiting until I could make it more robust to get public comments... Alas, I got caught up in creating a start-up (of which this PublicDomain set of classes is an off-shoot). I guess the cat's out of the bag :-) That's okay, and if anyone is interested in contributing, that would be greatly appreciated. A response to the questions is below.... On 6/21/07, Paul Eggert wrote: > "Olson, Arthur David (NIH/NCI) [E]" writes: > > > From: Joshua Kifer [mailto:joshua at jotts.com] > > Sent: Wednesday, June 20, 2007 8:33 PM > > > > http://www.codeplex.com/publicdomain > > Thanks for mentioning that. Do you know how it works? It appears to > have a copy of the tz database, translated into C# (how?). There is a class called TzDatabase which parses the tz database into logical constructs, then emits C# code, which is manually placed into the static initializer, and the whole package is recompiled. This adds a few seconds to each static initialization of the class, which is the trade off for not performing File I/O on DLL resources or the filesystem (mostly for security permission reasons). > > Suppose a new version of the tz database comes out: how would the > change be propagated? > A new version of PublicDomain would have to be created and this new DLL would be re-downloaded and installed (no automatic way of doing this). I am *very* open to criticisms. If there is a better way to implement tz database support, I would be interested; however, one of the main design goals was to require very little from the "integrator" (i.e. the consumer of PublicDomain and TzTimeZone/TzDateTime). Therefore, using resource files which must be loaded from the DLL or file system would require FileIOPermission, and I felt that a larger load time (due to static initialization) and the tz database compiled in was the better choice. I am open to changing this. By the way, if you install PublicDomain.msi, all code is placed into C:\Program Files\PublicDomain\ (it is not yet tested on Linux), including TzDatabase.cs, TzDateTime.cs, and TzTimeZone.cs. Thanks, Kevin Grigorenko From hellosticky at gmail.com Sun Jul 1 14:37:53 2007 From: hellosticky at gmail.com (Kevin) Date: Sun, 1 Jul 2007 10:37:53 -0400 Subject: FW: Implementation of zoneinfo (Olson, tz) database in .NET c-sharp csharp In-Reply-To: <6936856c0707010726k7c48f255t3f7c499de89222ca@mail.gmail.com> References: <87bqf9tdlu.fsf@penguin.cs.ucla.edu> <6936856c0707010726k7c48f255t3f7c499de89222ca@mail.gmail.com> Message-ID: <6936856c0707010737m50b4b270te6d4c37ec6a35017@mail.gmail.com> "Joshua Kifer" writes: >> the only thing being retained is the timezone name and its UTC >> offset. No historical data is utilized. > > Thanks. Here's a draft of what could go into tz-link.htm; comments > and corrections are welcome. > >
  • PublicDomain > has a copy of a recent tz database, accessed via a href="http://en.wikipedia.org/wiki/C_Sharp">C# library. As its > name suggests, it is in the public domain. Only current time stamps > are supported; historical data are not used.
    • By the way, the historical data exists, I just haven't implemented accessor methods to retrieve that data. This data is already compiled in to the runtime binary. However, it can be retrieved manually through the TzDatabase class, although that requires a local copy of the tz database. Thanks, Kevin From emuller at adobe.com Sun Jul 1 17:07:11 2007 From: emuller at adobe.com (Eric Muller) Date: Sun, 01 Jul 2007 10:07:11 -0700 Subject: Geographical boundaries for the continental US tz zones In-Reply-To: <465E634D.2080301@adobe.com> References: <465E634D.2080301@adobe.com> Message-ID: <4687DF3F.2080005@adobe.com> I have completed a first version of a map of the TZ timezones in the US. It is available as a shapefile at . Comments welcome, Eric. From CLawrence at stopwatchmaps.com Sun Jul 1 18:38:00 2007 From: CLawrence at stopwatchmaps.com (Christina Lawrence) Date: Sun, 1 Jul 2007 13:38:00 -0500 Subject: TimeZones and international waters In-Reply-To: <877ipxtcnp.fsf@penguin.cs.ucla.edu> Message-ID: Thank you for the response! What distance from shore defines "the territorial waters of any nation"? Is it nation specific, or an internationally recognized distance from shore? Thank you! Christina -----Original Message----- From: Paul Eggert [mailto:eggert at CS.UCLA.EDU] Sent: Thursday, June 21, 2007 12:56 PM To: tz at elsie.nci.nih.gov Cc: Christina Lawrence Subject: Re: TimeZones and international waters To help clear this up I'll add something like the following to my next proposed patch. Comments welcome. A ship within the territorial waters of any nation uses that nation's time. In international waters, time zone boundaries are meridians 15° apart, except that UTC−12 and UTC+12 are each 7.5° wide and are separated by the 180° meridian (not by the International Date Line, which is for land and territorial waters only). A captain can change ship's clocks any time after entering a new time zone; midnight changes are common. From pgoyette at juniper.net Sun Jul 1 18:50:08 2007 From: pgoyette at juniper.net (Paul Goyette) Date: Sun, 1 Jul 2007 11:50:08 -0700 Subject: TimeZones and international waters In-Reply-To: Message-ID: Generally, the territorial waters extend 12 miles from shore. In cases of conflict (ie, a point is less than 12 miles from the shores of two or more countries), the dividing line is established by treaty. I think there are still a few areas where treaties have not been adopted, so there might be some "gray" areas... International Treaties permit definition of "Economic Excclusion Zones" (the US EEZ is a 200-mile limit). Fishing limits apply in such areas, but boarding rights and controls over shipping etc. don not apply. Paul Goyette Juniper Networks Customer Service and former skipper of the 61' Cheoy Lee motor yacht "Gentle Wind" on her 2005 journey across the Pacific Ocean. > -----Original Message----- > From: Christina Lawrence [mailto:CLawrence at stopwatchmaps.com] > Sent: Sunday, July 01, 2007 11:38 AM > To: Paul Eggert > Cc: tz at lecserver.nci.nih.gov > Subject: RE: TimeZones and international waters > > Thank you for the response! > > What distance from shore defines "the territorial waters of > any nation"? > Is it nation specific, or an internationally recognized distance from > shore? > > Thank you! > > Christina > > > -----Original Message----- > From: Paul Eggert [mailto:eggert at CS.UCLA.EDU] > Sent: Thursday, June 21, 2007 12:56 PM > To: tz at elsie.nci.nih.gov > Cc: Christina Lawrence > Subject: Re: TimeZones and international waters > > To help clear this up I'll add something like the following to my next > proposed patch. Comments welcome. > > A ship within the territorial waters of any nation uses that nation's > time. In international waters, time zone boundaries are meridians > 15° apart, except that UTC−12 and UTC+12 are each 7.5° > wide and are separated by the 180° meridian (not by the > International Date Line, which is for land and territorial waters > only). A captain can change ship's clocks any time after entering a > new time zone; midnight changes are common. > From emuller at adobe.com Mon Jul 2 17:12:08 2007 From: emuller at adobe.com (Eric Muller) Date: Mon, 02 Jul 2007 10:12:08 -0700 Subject: French Polynesia Message-ID: <468931E8.7010206@adobe.com> If I read correctly the tz data for French Polynesia, there are three tz zones that are half an hour apart. I searched for an independent confirmation, but I can't find any evidence that FP has multiple local times. The best I have found so far is which suggests that all of FP is in a single timezone. Any idea of the source of the current data? Thanks, Eric. From wide.screen.software at mac.com Tue Jul 3 05:47:06 2007 From: wide.screen.software at mac.com (WIDE SCREEN SOFTWARE, LLC) Date: Mon, 2 Jul 2007 22:47:06 -0700 Subject: French Polynesia In-Reply-To: <468931E8.7010206@adobe.com> References: <468931E8.7010206@adobe.com> Message-ID: <379DAAE7-692F-4FF2-AD40-6301DBDEF615@mac.com> On Jul 2, 2007, at 10:12 AM, Eric Muller wrote: > If I read correctly the tz data for French Polynesia, there are > three tz zones that are half an hour apart. I searched for an > independent confirmation, but I can't find any evidence that FP has > multiple local times. The best I have found so far is > decouvrir_outre_mer/polynesie_francaise/ > publi_P_vie_pratique___decalage_horaire_1125327034760> > which suggests that all of FP is in a single timezone. > > Any idea of the source of the current data? > > Thanks, > Eric. > > > Eric, I am away working on location. I do not know if my wife had a chance to respond to your question. Check the following source that confirms the 3 time zones. http://home-4.tiscali.nl/~t876506/TZworld.html#pac If you have any questions please email. David Parrish (....on location) Wide Screen Software, LLC info at wide-screen.com http://www.wide-screen.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/tz/attachments/20070702/23b6c652/attachment-0001.html From jnorgard at prodigy.net.mx Mon Jul 9 01:08:01 2007 From: jnorgard at prodigy.net.mx (Jesper Norgaard Welen) Date: Sun, 08 Jul 2007 20:08:01 -0500 Subject: French Polynesia time zones Message-ID: Perhaps the following link will interest Eric Muller and the rest of the mailing list members: http://www.timegenie.com/country.time/pf/ The FAQ mentioned of the Tahiti tourism web site in fact has the URL http://www.tahiti-tourisme.com/planner/tahitifaqs.asp (it seems to have changed name since timegenie site documented it). Eric asked for a recognition of the three time zones in the tz database for French Polynesia. The explanation in the timegenie web site is: "According to the official Tahiti Tourisme web site, Tahiti and her Islands have two times zones. This information can be found in the FAQ section. However, Tahiti and her islands have in fact three time zones. The third time zone is not mentioned on the Tahiti Tourisme web site. Most likely, the third time zone is not mentioned since it is not visited by many tourists due to its distance from the main island of Tahiti. Since there is no official mention of the third time zone, timegenie.com contacted a Tahiti Tourisme office by phone. The result was that timegenie.com received official confirmation of the third time zone. Based on the information provided by Tahiti Tourisme, the majority of the islands, including the island of Tahiti itself, are -10 hours UTC/GMT. The Marquesas Islands are -9 hours 30 minutes UTC/GMT. The Gambier Islands are the third time zone and they are -9 hours UTC/GMT." I hope it's alright to quote timegenie for this information. I haven't found myself an official French Polynesia goverment web site confirming this information, but my french is limited to a 40-hour course so it is not to much use in this investigation. Regards, - Jesper Jesper N?rgaard Welen Email: jnorgard at Prodigy.Net.mx Project Leader (L?der de Proyecto) Software CIMMYT - Centro Internacional de Mejoramiento de Ma?z y Trigo Direcci?n: CIMMYT Int. c/o Jesper N?rgaard Km. 45, Carretera M?xico-Veracruz El Bat?n Texcoco, Edo. de M?xico CP 56130 MEXICO Tel.: +52 (55) 58-04-20-04 ext. 1374 Fax: +52 (55) 58-04-75-58 Tel. Casa: 53-10-05-95 ? 53-10-97-78 Download the shareware program World Time Explorer, I made: http://www.worldtimeexplorer.com/index.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/tz/attachments/20070708/07a537d5/attachment-0001.html From tkpublic at timklein.fastmail.fm Tue Jul 10 00:56:08 2007 From: tkpublic at timklein.fastmail.fm (Tim Klein) Date: Mon, 9 Jul 2007 19:56:08 -0500 Subject: Is there a list of "current" time zones? Message-ID: I'm new here. As I look through the tz database, and the archives of this mailing list, I realize what a phenomenal effort you folks have put in, to make all of this information available. Thank you for all you've done! A question... I'm helping to write an application that needs a menu for the user to choose what time zone they live in. With ~400 time zones in the database, that'd be a pretty daunting pull-down menu. But as I understand it, a significant fraction of the ~400 time zones exist only for historical reasons. Since our application will deal only with current and future times, historical distinctions don't matter, and we'd like the menu to show only the subset of time zones that are currently "in effect". (And we don't mind if it isn't painstakingly accurate or updated in real time.) Has anyone created such a list? Or maybe an algorithm (if not code) for generating one from the full database? I see that this question has come up in the past. To quote from the archives... ====== >From: "Andy Lipscomb" >Perhaps a better term would be "historical" time zones. This would >in fact be a useful distinction, since only a relatively small >subset of the timezones are necessary for applications that look >only forward--these would be the first set to present to a user for >selecting a time zone, with a "show all" option to get the complete >list. (For example, the 50 United States can be covered on a >forward-looking basis by eight zones--New York, Chicago, Denver, >Phoenix, Los Angeles, Anchorage, Adak, and Honolulu. And if one >takes as irrevocable the power of the EU over DST dates, then--for >example--London, Paris, and Helsinki would cover that entire area, >except for the different abbreviations used in the three +0 >countries.) ====== And... >From: Paul Eggert [mailto:eggert at CS.UCLA.EDU] >Sent: November 6, 2006 12:13 PM > >> Is there any way to flag some of the old historical zones such that >> they don't appear when running "tzselect"? > >We could have a table for people who don't care about historical >times, which maps zone names to "modern" zone names, and tzselect >could have an option to use that table. ====== Thank you very much for any wisdom on this subject! Tim Klein Dallas, Texas, USA From eulevik at gmail.com Tue Jul 10 01:56:21 2007 From: eulevik at gmail.com (Eric Ulevik) Date: Tue, 10 Jul 2007 11:56:21 +1000 Subject: Is there a list of "current" time zones? In-Reply-To: References: Message-ID: On 7/10/07, Tim Klein wrote: > I'm helping to write an application that needs a menu for the user to > choose what time zone they live in. With ~400 time zones in the > database, that'd be a pretty daunting pull-down menu. You will find this menu in quite a few places. Generally people don't have a problem identifying their geographical location - which is what this list shows. To simplify the menu, get the user to first choose a continent (eg. "Australia" or "Europe") then a region from a smaller list. You could also move the most common selections to the top of the list. Regards, Eric Ulevik From philip.howell at evalua.com.au Tue Jul 10 02:21:25 2007 From: philip.howell at evalua.com.au (Philip Howell) Date: Tue, 10 Jul 2007 12:21:25 +1000 Subject: Is there a list of "current" time zones? In-Reply-To: <"a06240819c2b88521e5ea(a)(091)192.168.1.104(093)*"@MHS> References: <"a06240819c2b88521e5ea(a)(091)192.168.1.104(093)*"@MHS> Message-ID: <4692ED25.4080904@evalua.com.au> Hi Tim, In the tzdata tarball is a file called zone.tab. It lists the current time zones grouped by country code. Cheers, Phil Tim Klein wrote: > I'm new here. As I look through the tz database, and the archives of > this mailing list, I realize what a phenomenal effort you folks have > put in, to make all of this information available. Thank you for all > you've done! > > A question... > > I'm helping to write an application that needs a menu for the user to > choose what time zone they live in. With ~400 time zones in the > database, that'd be a pretty daunting pull-down menu. > > But as I understand it, a significant fraction of the ~400 time zones > exist only for historical reasons. Since our application will deal > only with current and future times, historical distinctions don't > matter, and we'd like the menu to show only the subset of time zones > that are currently "in effect". (And we don't mind if it isn't > painstakingly accurate or updated in real time.) > > Has anyone created such a list? Or maybe an algorithm (if not code) > for generating one from the full database? > > I see that this question has come up in the past. To quote from the > archives... > > ====== > >> From: "Andy Lipscomb" >> Perhaps a better term would be "historical" time zones. This would in >> fact be a useful distinction, since only a relatively small subset of >> the timezones are necessary for applications that look only >> forward--these would be the first set to present to a user for >> selecting a time zone, with a "show all" option to get the complete >> list. (For example, the 50 United States can be covered on a >> forward-looking basis by eight zones--New York, Chicago, Denver, >> Phoenix, Los Angeles, Anchorage, Adak, and Honolulu. And if one takes >> as irrevocable the power of the EU over DST dates, then--for >> example--London, Paris, and Helsinki would cover that entire area, >> except for the different abbreviations used in the three +0 countries.) > > ====== > And... > >> From: Paul Eggert [mailto:eggert at CS.UCLA.EDU] >> Sent: November 6, 2006 12:13 PM >> >>> Is there any way to flag some of the old historical zones such that >>> they don't appear when running "tzselect"? >> >> We could have a table for people who don't care about historical >> times, which maps zone names to "modern" zone names, and tzselect >> could have an option to use that table. > > ====== > > Thank you very much for any wisdom on this subject! > > Tim Klein > Dallas, Texas, USA > > From olsona at dc37a.nci.nih.gov Tue Jul 10 13:29:20 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Tue, 10 Jul 2007 09:29:20 -0400 Subject: FW: Time Zone mapping --> Windows ??? Message-ID: I'm forwarding this message from Boris Lang, who is not on the time zone mailing list. Those of you who are on the time zone mailing list should direct replies appropriately. --ado -----Original Message----- From: BORIS LANG [mailto:BORIS.LANG at MEMO.IKEA.COM] Sent: Tuesday, July 10, 2007 8:55 AM To: tz at lecserver.nci.nih.gov Subject: Time Zone mapping --> Windows ??? --- Received from IKEA4.BRLG +49 6122 5858276 07-07-10 14.56 -------------------------------------- Hi, we are working on the implementation of time zone information into an application using the tz database. TZ data names will be our main type but we also need to do a mapping to the time zone names used in windows. i.e. Europe/Berlin (tzd) --> Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna (Windows) The problem is that I can?t find a complete list that contains the mapping from tz database to windows. Can somebody please help us? Is there already such a list existing? Best regards Boris Lang ------ IKEA IT Germany GmbH Am Wandersmann 2-4 65719 Hofheim-Wallau Sitz M?nchen HR B 79392, Amtsgericht M?nchen Gesch?ftsf?hrer: Manfred Godlewski, G?ran Sj?strand, Ola Troedsson ---- 07-07-10 14.56 ---- Sent to --------------------------------------------------------------------------------- -> tz at elsie.nci.nih.gov From GMANE at faerber.muc.de Tue Jul 10 09:42:23 2007 From: GMANE at faerber.muc.de (=?ISO-8859-1?Q?Claus_F=E4rber?=) Date: Tue, 10 Jul 2007 11:42:23 +0200 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: References: Message-ID: Andy Lipscomb schrieb: > As was largely hashed out over China, changing to Hanoi would in fact *not* be consistent--the standard is largest city, not necessarily capital. (For example, Australia, Canada, China, India, New Zealand, South Africa, and the USA do not have explicit listings for their capital cities.) I argued that Beijing should be in because of its significance in determining Chinese-calendar dates, but lost that one. As for what to call any given city, on that I have no opinion. As the term city is ambiguous, the standard is ambiguous and inconsistent anyway. If city is defined as municipality, the following are wrong: Europe/London should be Europe/Birmingham Asia/Tokyo should be Asia/Yokohama Australia/Sydney should be Australia/Blacktown ... and probably dozens others. The largest "cities" often consist of multiple municipalities, which makes this definition insensible. However, if city is defined as metropolitan area, the following are clearly wrong: Europe/Berlin should be Europe/Rhein-Rhur Europe/Rome should be Europe/Milan Asia/Calcutta should be Asia/Mumbai Asia/Karachi should be Asia/Lahor IMO, the standard should be changed from "largest city" to "most important city". Importance would be primarily derived from the population count but with respect to factors such as legal status (city, capital) and views of the local population. Claus From dot at dotat.at Tue Jul 10 14:59:31 2007 From: dot at dotat.at (Tony Finch) Date: Tue, 10 Jul 2007 15:59:31 +0100 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: References: Message-ID: On Tue, 10 Jul 2007, Claus F?rber wrote: > > If city is defined as municipality, the following are wrong: > > Europe/London should be Europe/Birmingham Not if it's London as in the Greater London Authority (or, historically, the Greater London Council, the London County Council, etc.), as opposed to the City of London which has been only a small part of the geography and government of the greater city for centuries. Tony. -- f.a.n.finch http://dotat.at/ IRISH SEA: NORTHWEST 4 OR 5, OCCASIONALLY 6. SLIGHT OR MODERATE. SHOWERS. MAINLY GOOD. From GMANE at faerber.muc.de Tue Jul 10 16:13:14 2007 From: GMANE at faerber.muc.de (=?UTF-8?B?Q2xhdXMgRsOkcmJlcg==?=) Date: Tue, 10 Jul 2007 18:13:14 +0200 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: References: Message-ID: Tony Finch schrieb: > On Tue, 10 Jul 2007, Claus F?rber wrote: >> If city is defined as municipality, the following are wrong: >> >> Europe/London should be Europe/Birmingham > > Not if it's London as in the Greater London Authority (or, historically, > the Greater London Council, the London County Council, etc.), as opposed > to the City of London which has been only a small part of the geography > and government of the greater city for centuries. The GLA is a super-city authority, covering multiple cities such as the City of London, the City of Westminster, etc. Well, that just proves my point that the term "city" introduces ambiguity. It's simply inconsistent to treat Greater London as a "city", which is made up of multiple municipalities like the City of London, Westminster, etc., but not the Ruhrgebiet (5.3 million and thus larger than Berlin, 3.4 million), which is made up of municipalities like Essen, Bochum or Dortmund and also has a super-city authority: the Regionalverband Ruhr (RVR). It's also inconsistent to treat Greater London as a "city" and not Greater Milan (7 million), which would be substantially larger than Rome or Greater Rome (2.5 or 3.3 million). Bending the rules in similar ways, Shanghai (??) suddenly has a population of 9.4 millions (the agglomeration, not the larger administrative area) and Beijing (??) has 11.5 millions (the agglomeration, not the administrative area and not the "core city"). It does not work with Saigon/Ho Chi Minh City (Th?nh ph? H? Ch? Minh) and Hanoi (H? N?i), though. Claus From vuntz at gnome.org Tue Jul 10 17:23:50 2007 From: vuntz at gnome.org (Vincent Untz) Date: Tue, 10 Jul 2007 19:23:50 +0200 Subject: Localization of timezones from zone.tab Message-ID: <20070710172350.GI30640@vuntz.net> Hi, [please keep me cc'ed since I'm not subscribed to this list] I know that, at least in GNOME, there are now three places where we parse zone.tab to get a list of timezones supported by the OS. I suppose other projects are also doing this. This list is then presented to the user to let him choose the timezone. The problem here is that we let the user choose strings which look like "Antarctica/South_Pole". This is not really good for non-english-speaking people ;-) Of course, we can add all the timezones to our list of strings to translate, but this means all projects needing to do so will duplicate this work and the translations. I'd like the tz database to ship translations in po files. This would imply the following: + create a small script to generate a POT file from zone.tab (easy) + submit the POT file to the translation project [1] (or any other place that helps with translation) + add the po files for translation to the tz database + choose a gettext domain (Of course, I'm quite probably forgetting about a step :-)) I've seen that this topic has been discussed before [2], but the proposition there was really more ambitious, so I'm hoping a simple approach would be welcomed. What do you think? Thanks, [1] http://translationproject.org/ [2] http://osdir.com/ml/time.tz/2004-09/msg00000.html Vincent -- Les gens heureux ne sont pas press?s. From olsona at dc37a.nci.nih.gov Tue Jul 10 17:26:23 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Tue, 10 Jul 2007 13:26:23 -0400 Subject: FW: Localization of timezones from zone.tab Message-ID: I'm forwarding this message from Vincent Untz, who is not on the time zone mailing list. Those of you who are on the time zone mailing list should direct replies appropriately. --ado -----Original Message----- From: Vincent Untz [mailto:vuntz at gnome.org] Sent: Tuesday, July 10, 2007 1:24 PM To: tz at lecserver.nci.nih.gov Subject: Localization of timezones from zone.tab Hi, [please keep me cc'ed since I'm not subscribed to this list] I know that, at least in GNOME, there are now three places where we parse zone.tab to get a list of timezones supported by the OS. I suppose other projects are also doing this. This list is then presented to the user to let him choose the timezone. The problem here is that we let the user choose strings which look like "Antarctica/South_Pole". This is not really good for non-english-speaking people ;-) Of course, we can add all the timezones to our list of strings to translate, but this means all projects needing to do so will duplicate this work and the translations. I'd like the tz database to ship translations in po files. This would imply the following: + create a small script to generate a POT file from zone.tab (easy) + submit the POT file to the translation project [1] (or any other place that helps with translation) + add the po files for translation to the tz database + choose a gettext domain (Of course, I'm quite probably forgetting about a step :-)) I've seen that this topic has been discussed before [2], but the proposition there was really more ambitious, so I'm hoping a simple approach would be welcomed. What do you think? Thanks, [1] http://translationproject.org/ [2] http://osdir.com/ml/time.tz/2004-09/msg00000.html Vincent -- Les gens heureux ne sont pas press?s. From AndyLipscomb at decosimo.com Tue Jul 10 17:34:11 2007 From: AndyLipscomb at decosimo.com (Andy Lipscomb) Date: Tue, 10 Jul 2007 13:34:11 -0400 Subject: Localization of timezones from zone.tab In-Reply-To: Message-ID: Currently, the main effort to localize time-zone information is in the Common Language Data Repository (I think that's what it's called, I know it's CLDR for initials), hosted at http://www.unicode.org/cldr; for each zone, there is the option to localize two names (DST and standard), the initials for those names, and the example city. J Andrew Lipscomb, CPA*ABV, ASA Decosimo Corporate Finance 900 Tallan Building 2 Union Square Chattanooga, TN 37402 423.756.7100 Fax 423.266.6671 www.dcf.decosimo.com -----Original Message----- From: Olson, Arthur David (NIH/NCI) [E] [mailto:olsona at dc37a.nci.nih.gov] Sent: Tue 10 July 2007 13:26 To: tz at lecserver.nci.nih.gov Cc: vuntz at gnome.org Subject: FW: Localization of timezones from zone.tab I'm forwarding this message from Vincent Untz, who is not on the time zone mailing list. Those of you who are on the time zone mailing list should direct replies appropriately. --ado -----Original Message----- From: Vincent Untz [mailto:vuntz at gnome.org] Sent: Tuesday, July 10, 2007 1:24 PM To: tz at lecserver.nci.nih.gov Subject: Localization of timezones from zone.tab Hi, [please keep me cc'ed since I'm not subscribed to this list] I know that, at least in GNOME, there are now three places where we parse zone.tab to get a list of timezones supported by the OS. I suppose other projects are also doing this. This list is then presented to the user to let him choose the timezone. The problem here is that we let the user choose strings which look like "Antarctica/South_Pole". This is not really good for non-english-speaking people ;-) Of course, we can add all the timezones to our list of strings to translate, but this means all projects needing to do so will duplicate this work and the translations. I'd like the tz database to ship translations in po files. This would imply the following: + create a small script to generate a POT file from zone.tab (easy) + submit the POT file to the translation project [1] (or any other place that helps with translation) + add the po files for translation to the tz database + choose a gettext domain (Of course, I'm quite probably forgetting about a step :-)) I've seen that this topic has been discussed before [2], but the proposition there was really more ambitious, so I'm hoping a simple approach would be welcomed. What do you think? Thanks, [1] http://translationproject.org/ [2] http://osdir.com/ml/time.tz/2004-09/msg00000.html Vincent -- Les gens heureux ne sont pas press?s. From mark.davis at icu-project.org Tue Jul 10 17:44:14 2007 From: mark.davis at icu-project.org (Mark Davis) Date: Tue, 10 Jul 2007 10:44:14 -0700 Subject: FW: Localization of timezones from zone.tab In-Reply-To: References: Message-ID: <30b660a20707101044n2c21c123l19f9b718d4bb5050@mail.gmail.com> The Unicode CLDR project (http://unicode.org/cldr/) does supply translations for timezone IDs. There are a few caveats. 1. The timezone database really has equivalence classes of IDs. One of these can be used as a representative for any in the equivalence class. It is the zone.tab file that contains such IDs. CLDR started by using that file, but unfortunately it is not stable (different equivalent IDs can be substituted at any time). So what we do is use as the representative the one that historically the first one used in any zone.tab file (after CLDR started). 2. We allow, but do not encourage, translation of zones that are the only zone in a country. For that we use the country name. This cuts down very substantially on the number of translations needed. That is, you would see the equivalent of "Italy", and "United States (Los Angeles)" -- only in the latter case do we need translations for the cities. 3. Translators can optionally add other variations: daylight (summer) time, standard (winter) time, and generic time, both abbreviated and long. 4. These choices percolate out to clients of CLDR: Google, IBM, Apple, Adobe, and many others. Mark On 7/10/07, Olson, Arthur David (NIH/NCI) [E] wrote: > > I'm forwarding this message from Vincent Untz, who is not on the time zone > mailing list. > > Those of you who are on the time zone mailing list should direct replies > appropriately. > > --ado > > -----Original Message----- > From: Vincent Untz [mailto:vuntz at gnome.org] > Sent: Tuesday, July 10, 2007 1:24 PM > To: tz at lecserver.nci.nih.gov > Subject: Localization of timezones from zone.tab > > Hi, > > [please keep me cc'ed since I'm not subscribed to this list] > > I know that, at least in GNOME, there are now three places where we > parse zone.tab to get a list of timezones supported by the OS. I suppose > other projects are also doing this. This list is then presented to the > user to let him choose the timezone. > > The problem here is that we let the user choose strings which look like > "Antarctica/South_Pole". This is not really good for > non-english-speaking people ;-) > > Of course, we can add all the timezones to our list of strings to > translate, but this means all projects needing to do so will duplicate > this work and the translations. > > I'd like the tz database to ship translations in po files. This would > imply the following: > > + create a small script to generate a POT file from zone.tab (easy) > + submit the POT file to the translation project [1] (or any other > place that helps with translation) > + add the po files for translation to the tz database > + choose a gettext domain > > (Of course, I'm quite probably forgetting about a step :-)) > > I've seen that this topic has been discussed before [2], but the > proposition there was really more ambitious, so I'm hoping a simple > approach would be welcomed. > > What do you think? > > Thanks, > > [1] http://translationproject.org/ > [2] http://osdir.com/ml/time.tz/2004-09/msg00000.html > > Vincent > > -- > Les gens heureux ne sont pas press?s. > -- Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/tz/attachments/20070710/f31b97a1/attachment-0001.html From rlaw at nc.rr.com Tue Jul 10 18:38:02 2007 From: rlaw at nc.rr.com (rlaw at nc.rr.com) Date: Tue, 10 Jul 2007 14:38:02 -0400 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: References: Message-ID: > As the term city is ambiguous, the standard is ambiguous and > inconsistent anyway. How can we put an end to the incessant disputation over time zone identifiers? If we go by metropolitan area populations, someone will say we should go by central city populations. If we use any criterion that chooses Hanoi, someone will say Ho Chi Minh City is more important; but others will argue that the capital city is always more important. We must bear in mind that these are only supposed to be identifiers. Conceptually, we could be using WT/QAF just as well as Europe/Rome. It was merely for the convenience of developers that mnemonic names were chosen. But it is the responsibility of a user interface, not of the tz database, to translate the time zone identifiers into user-friendly names. The volunteer maintainers of the tz database have plenty of work to do, just to keep it up to date. If their job description is expanded to include making sure that the definitions of cities are consistent, providing universally acceptable names and abbreviations for time zones, or enabling localization by giving the translations of city, country, and time zone names into an arbitrary number of languages, I believe that puts too much on their plate. Presumably the CLDR addresses localization issues. Whoever maintains the CLDR has undertaken responsibility for interpreting the identifiers into human-readable form. Identifiers should be stable, too. True, by using backward-compatibility links, we can minimize the disruption caused by changing an identifier. Still, any kind of change has its cost, and a lot of the cost is hidden. We don't know how many people have used "Europe/Rome" somewhere in their code or nomenclature or documentation, and would deem it necessary to change the string if the primary name of that time zone changed to "Europe/Milan". (Of course, some changes are unavoidable, when time zones split.) My suggestion would be to state boldly in the documentation, "Time zone identifiers are arbitrary. Although they look as if they have a geographic interpretation, there is no guarantee that they do, or will continue to in the future. They should not be displayed directly to end users." Then, if possible, there should be some discussion of how to display time zone information to users. If we get GIS files for time zone boundaries, that will be a big help. Maintaining the boundary files would fall within the purview of the tz mailing list. Gwillim Law From chucks2 at veladg.com Tue Jul 10 20:37:17 2007 From: chucks2 at veladg.com (Chuck Soper) Date: Tue, 10 Jul 2007 13:37:17 -0700 Subject: FW: Localization of timezones from zone.tab Message-ID: I've been on the tz list for several years. I have tried to follow the Time Zone Localizations topic for CLDR. I do not understand why translations would be supplied for timezone IDs (tzIDs). Many tzIDs refer to the same time zone name. For example, I believe that Argentina has 2 time zone names, yet it has 10 tzIDs to handle DST rules for various states. Does this mean that 20 localized names would be required for Argentina? Does this mean that a new tzID would not be localized? Looking at 381 tzIDs of a tzData version (from 2006), I multiply it by two (for std and dst names) to obtain 762 time zone names required. By removing names of tzIDs that do not recognize DST and removing tzIDs that refer to the same time name (e.g. many tzIDs refer to Central European Time), I was to reduce total time zone names from 762 to 212. Can over 500 names can be removed from the translation list? Multiplying 500 potentially unneeded names by the number of translations would result in a large reduction of translation efforts. My approach is dependent on having a stable list of time zone names. As far as I know, such a list does not exist. If such a list existed, I would envision tzIDs being mapped to the 'time zone name' list. Chuck At 10:44 AM -0700 7/10/07, Mark Davis wrote: >The Unicode CLDR project >(http://unicode.org/cldr/) >does supply translations for timezone IDs. There >are a few caveats. > >1. The timezone database really has >equivalence classes of IDs. One of these can be >used as a representative for any in the >equivalence class. It is the zone.tab file that >contains such IDs. CLDR started by using that >file, but unfortunately it is not stable >(different equivalent IDs can be substituted at >any time). So what we do is use as the >representative the one that historically the >first one used in any zone.tab file (after CLDR >started). >2. We allow, but do not encourage, >translation of zones that are the only zone in a >country. For that we use the country name. This >cuts down very substantially on the number of >translations needed. That is, you would see the >equivalent of "Italy", and "United States (Los >Angeles)" -- only in the latter case do we need >translations for the cities. >3. Translators can optionally add other >variations: daylight (summer) time, standard >(winter) time, and generic time, both >abbreviated and long. >4. These choices percolate out to clients of >CLDR: Google, IBM, Apple, Adobe, and many others. > >Mark > >On 7/10/07, Olson, Arthur David (NIH/NCI) [E] ><olsona at dc37a.nci.nih.gov> >wrote: > >I'm forwarding this message from Vincent Untz, >who is not on the time zone mailing list. > >Those of you who are on the time zone mailing >list should direct replies appropriately. > > --ado > >-----Original Message----- >From: Vincent Untz [mailto: vuntz at gnome.org] >Sent: Tuesday, July 10, 2007 1:24 PM >To: tz at lecserver.nci.nih.gov >Subject: Localization of timezones from zone.tab > >Hi, > >[please keep me cc'ed since I'm not subscribed to this list] > >I know that, at least in GNOME, there are now three places where we >parse zone.tab to get a list of timezones supported by the OS. I suppose >other projects are also doing this. This list is then presented to the >user to let him choose the timezone. > >The problem here is that we let the user choose strings which look like >"Antarctica/South_Pole". This is not really good for >non-english-speaking people ;-) > >Of course, we can add all the timezones to our list of strings to >translate, but this means all projects needing to do so will duplicate >this work and the translations. > >I'd like the tz database to ship translations in po files. This would >imply the following: > >+ create a small script to generate a POT file from zone.tab (easy) >+ submit the POT file to the translation project [1] (or any other > place that helps with translation) >+ add the po files for translation to the tz database >+ choose a gettext domain > >(Of course, I'm quite probably forgetting about a step :-)) > >I've seen that this topic has been discussed before [2], but the >proposition there was really more ambitious, so I'm hoping a simple >approach would be welcomed. > >What do you think? > >Thanks, > >[1] http://translationproject.org/ >[2] > >http://osdir.com/ml/time.tz/2004-09/msg00000.html > >Vincent > >-- >Les gens heureux ne sont pas press?s. > > > > >-- >Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/tz/attachments/20070710/4371bf99/attachment-0001.html From mark.davis at icu-project.org Tue Jul 10 20:54:19 2007 From: mark.davis at icu-project.org (Mark Davis) Date: Tue, 10 Jul 2007 13:54:19 -0700 Subject: FW: Localization of timezones from zone.tab In-Reply-To: References: Message-ID: <30b660a20707101354o58134e03l817d61b0778af44c@mail.gmail.com> We have actually instituted an alternative mechanism called 'metazones', which are somewhat like what you describe. They basically coalesce zones that have the same behavior in modern time. However, they have some further restrictions, and we only put this in recently thus haven't gathered enough data to be useful yet. Mark On 7/10/07, Chuck Soper wrote: > > I've been on the tz list for several years. I have tried to follow the > Time Zone Localizations topic for CLDR. > > I do not understand why translations would be supplied for timezone IDs > (tzIDs). Many tzIDs refer to the same time zone name. For example, I believe > that Argentina has 2 time zone names, yet it has 10 tzIDs to handle DST > rules for various states. Does this mean that 20 localized names would be > required for Argentina? Does this mean that a new tzID would not be > localized? > > Looking at 381 tzIDs of a tzData version (from 2006), I multiply it by two > (for std and dst names) to obtain 762 time zone names required. By removing > names of tzIDs that do not recognize DST and removing tzIDs that refer to > the same time name (e.g. many tzIDs refer to Central European Time), I was > to reduce total time zone names from 762 to 212. > > Can over 500 names can be removed from the translation list? Multiplying > 500 potentially unneeded names by the number of translations would result in > a large reduction of translation efforts. > > My approach is dependent on having a stable list of time zone names. As > far as I know, such a list does not exist. If such a list existed, I would > envision tzIDs being mapped to the 'time zone name' list. > > Chuck > > > At 10:44 AM -0700 7/10/07, Mark Davis wrote: > > The Unicode CLDR project (http://unicode.org/cldr/) does supply > translations for timezone IDs. There are a few caveats. > > 1. The timezone database really has equivalence classes of IDs. One > of these can be used as a representative for any in the equivalence class. > It is the zone.tab file that contains such IDs. CLDR started by using that > file, but unfortunately it is not stable (different equivalent IDs can be > substituted at any time). So what we do is use as the representative the one > that historically the first one used in any zone.tab file (after CLDR > started). > > 2. We allow, but do not encourage, translation of zones that are the > only zone in a country. For that we use the country name. This cuts down > very substantially on the number of translations needed. That is, you would > see the equivalent of "Italy", and "United States (Los Angeles)" -- only in > the latter case do we need translations for the cities. > > 3. Translators can optionally add other variations: daylight (summer) > time, standard (winter) time, and generic time, both abbreviated and long. > > 4. These choices percolate out to clients of CLDR: Google, IBM, > Apple, Adobe, and many others. > > Mark > > On 7/10/07,* Olson, Arthur David (NIH/NCI) [E]* > wrote: > > I'm forwarding this message from Vincent Untz, who is not on the time zone > mailing list. > > Those of you who are on the time zone mailing list should direct replies > appropriately. > > --ado > > -----Original Message----- > From: Vincent Untz [mailto: vuntz at gnome.org] > Sent: Tuesday, July 10, 2007 1:24 PM > To: tz at lecserver.nci.nih.gov > Subject: Localization of timezones from zone.tab > > Hi, > > [please keep me cc'ed since I'm not subscribed to this list] > > I know that, at least in GNOME, there are now three places where we > parse zone.tab to get a list of timezones supported by the OS. I suppose > other projects are also doing this. This list is then presented to the > user to let him choose the timezone. > > The problem here is that we let the user choose strings which look like > "Antarctica/South_Pole". This is not really good for > non-english-speaking people ;-) > > Of course, we can add all the timezones to our list of strings to > translate, but this means all projects needing to do so will duplicate > this work and the translations. > > I'd like the tz database to ship translations in po files. This would > imply the following: > > + create a small script to generate a POT file from zone.tab (easy) > + submit the POT file to the translation project [1] (or any other > > place that helps with translation) > > + add the po files for translation to the tz database > + choose a gettext domain > > (Of course, I'm quite probably forgetting about a step :-)) > > I've seen that this topic has been discussed before [2], but the > proposition there was really more ambitious, so I'm hoping a simple > approach would be welcomed. > > What do you think? > > Thanks, > > [1] http://translationproject.org/ > [2] http://osdir.com/ml/time.tz/2004-09/msg00000.html > > Vincent > > -- > Les gens heureux ne sont pas press?s. > > > > > -- > Mark > > > -- Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/tz/attachments/20070710/1bb18f83/attachment-0001.html From chucks2 at veladg.com Tue Jul 10 21:49:10 2007 From: chucks2 at veladg.com (Chuck Soper) Date: Tue, 10 Jul 2007 14:49:10 -0700 Subject: FW: Localization of timezones from zone.tab In-Reply-To: <30b660a20707101354o58134e03l817d61b0778af44c@mail.gmail.com> References: <30b660a20707101354o58134e03l817d61b0778af44c@mail.gmail.com> Message-ID: Thanks for your response. I now remember meeting someone from IBM at an IMUG meeting at Apple; he described metazones. What is the best way for me to stay informed of CLDR related to time zones? And is there a way to make comments, suggestions or discuss? Chuck At 1:54 PM -0700 7/10/07, Mark Davis wrote: >We have actually instituted an alternative >mechanism called 'metazones', which are somewhat >like what you describe. They basically coalesce >zones that have the same behavior in modern >time. However, they have some further >restrictions, and we only put this in recently >thus haven't gathered enough data to be useful >yet. > >Mark > >On 7/10/07, Chuck Soper <chucks2 at veladg.com> wrote: > >I've been on the tz list for several years. I >have tried to follow the Time Zone Localizations >topic for CLDR. > >I do not understand why translations would be >supplied for timezone IDs (tzIDs). Many tzIDs >refer to the same time zone name. For example, I >believe that Argentina has 2 time zone names, >yet it has 10 tzIDs to handle DST rules for >various states. Does this mean that 20 localized >names would be required for Argentina? Does this >mean that a new tzID would not be localized? > >Looking at 381 tzIDs of a tzData version (from >2006), I multiply it by two (for std and dst >names) to obtain 762 time zone names required. >By removing names of tzIDs that do not recognize >DST and removing tzIDs that refer to the same >time name (e.g. many tzIDs refer to Central >European Time), I was to reduce total time zone >names from 762 to 212. > >Can over 500 names can be removed from the >translation list? Multiplying 500 potentially >unneeded names by the number of translations >would result in a large reduction of translation >efforts. > >My approach is dependent on having a stable list >of time zone names. As far as I know, such a >list does not exist. If such a list existed, I >would envision tzIDs being mapped to the 'time >zone name' list. > >Chuck > > >At 10:44 AM -0700 7/10/07, Mark Davis wrote: > >>The Unicode CLDR project >>(http://unicode.org/cldr/) >>does supply translations for timezone IDs. >>There are a few caveats. >> >>1. The timezone database really has >>equivalence classes of IDs. One of these can be >>used as a representative for any in the >>equivalence class. It is the zone.tab file that >>contains such IDs. CLDR started by using that >>file, but unfortunately it is not stable >>(different equivalent IDs can be substituted at >>any time). So what we do is use as the >>representative the one that historically the >>first one used in any zone.tab file (after CLDR >>started). >> >>2. We allow, but do not encourage, >>translation of zones that are the only zone in >>a country. For that we use the country name. >>This cuts down very substantially on the number >>of translations needed. That is, you would see >>the equivalent of "Italy", and "United States >>(Los Angeles)" -- only in the latter case do we >>need translations for the cities. >> >>3. Translators can optionally add other >>variations: daylight (summer) time, standard >>(winter) time, and generic time, both >>abbreviated and long. >> >>4. These choices percolate out to clients >>of CLDR: Google, IBM, Apple, Adobe, and many >>others. >> >Mark > >On 7/10/07, Olson, Arthur David (NIH/NCI) [E] ><olsona at dc37a.nci.nih.gov> >wrote: > >I'm forwarding this message from Vincent Untz, >who is not on the time zone mailing list. > >Those of you who are on the time zone mailing >list should direct replies appropriately. > > --ado > >-----Original Message----- >From: Vincent Untz [mailto: vuntz at gnome.org] >Sent: Tuesday, July 10, 2007 1:24 PM >To: tz at lecserver.nci.nih.gov >Subject: Localization of timezones from zone.tab > >Hi, > >[please keep me cc'ed since I'm not subscribed to this list] > >I know that, at least in GNOME, there are now three places where we >parse zone.tab to get a list of timezones supported by the OS. I suppose >other projects are also doing this. This list is then presented to the >user to let him choose the timezone. > >The problem here is that we let the user choose strings which look like >"Antarctica/South_Pole". This is not really good for >non-english-speaking people ;-) > >Of course, we can add all the timezones to our list of strings to >translate, but this means all projects needing to do so will duplicate >this work and the translations. > >I'd like the tz database to ship translations in po files. This would >imply the following: > >+ create a small script to generate a POT file from zone.tab (easy) >+ submit the POT file to the translation project [1] (or any other > > place that helps with translation) > >+ add the po files for translation to the tz database >+ choose a gettext domain > >(Of course, I'm quite probably forgetting about a step :-)) > >I've seen that this topic has been discussed before [2], but the >proposition there was really more ambitious, so I'm hoping a simple >approach would be welcomed. > >What do you think? > >Thanks, > >[1] http://translationproject.org/ >[2] > >http://osdir.com/ml/time.tz/2004-09/msg00000.html > >Vincent > >-- >Les gens heureux ne sont pas press?s. > > > > >-- >Mark > > > > > >-- >Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/tz/attachments/20070710/a12e1b21/attachment-0001.html From mark.davis at icu-project.org Tue Jul 10 22:05:53 2007 From: mark.davis at icu-project.org (Mark Davis) Date: Tue, 10 Jul 2007 15:05:53 -0700 Subject: FW: Localization of timezones from zone.tab In-Reply-To: References: <30b660a20707101354o58134e03l817d61b0778af44c@mail.gmail.com> Message-ID: <30b660a20707101505g3d545171o43fbf84ed35d6c59@mail.gmail.com> There is a users group at http://www.unicode.org/consortium/distlist.html#cldr_list. You can post suggestions/requests via the bug form on http://www.unicode.org/cldr/bugs/locale-bugs. If you belong to a Unicode member organization (http://www.unicode.org/consortium/memblogo.html) you can get on the internal list and even (if you choose) the weekly teleconference. Mark On 7/10/07, Chuck Soper wrote: > > Thanks for your response. I now remember meeting someone from IBM at an > IMUG meeting at Apple; he described metazones. > > What is the best way for me to stay informed of CLDR related to time > zones? And is there a way to make comments, suggestions or discuss? > > Chuck > > At 1:54 PM -0700 7/10/07, Mark Davis wrote: > > We have actually instituted an alternative mechanism called 'metazones', > which are somewhat like what you describe. They basically coalesce zones > that have the same behavior in modern time. However, they have some further > restrictions, and we only put this in recently thus haven't gathered enough > data to be useful yet. > > Mark > > On 7/10/07,* Chuck Soper* wrote: > > I've been on the tz list for several years. I have tried to follow the > Time Zone Localizations topic for CLDR. > > > I do not understand why translations would be supplied for timezone IDs > (tzIDs). Many tzIDs refer to the same time zone name. For example, I believe > that Argentina has 2 time zone names, yet it has 10 tzIDs to handle DST > rules for various states. Does this mean that 20 localized names would be > required for Argentina? Does this mean that a new tzID would not be > localized? > > > Looking at 381 tzIDs of a tzData version (from 2006), I multiply it by two > (for std and dst names) to obtain 762 time zone names required. By removing > names of tzIDs that do not recognize DST and removing tzIDs that refer to > the same time name (e.g. many tzIDs refer to Central European Time), I was > to reduce total time zone names from 762 to 212. > > > Can over 500 names can be removed from the translation list? Multiplying > 500 potentially unneeded names by the number of translations would result in > a large reduction of translation efforts. > > > My approach is dependent on having a stable list of time zone names. As > far as I know, such a list does not exist. If such a list existed, I would > envision tzIDs being mapped to the 'time zone name' list. > > > Chuck > > > > At 10:44 AM -0700 7/10/07, Mark Davis wrote: > > The Unicode CLDR project (http://unicode.org/cldr/) does supply > translations for timezone IDs. There are a few caveats. > > 1. The timezone database really has equivalence classes of IDs. One > of these can be used as a representative for any in the equivalence class. > It is the zone.tab file that contains such IDs. CLDR started by using that > file, but unfortunately it is not stable (different equivalent IDs can be > substituted at any time). So what we do is use as the representative the one > that historically the first one used in any zone.tab file (after CLDR > started). > > 2. We allow, but do not encourage, translation of zones that are the > only zone in a country. For that we use the country name. This cuts down > very substantially on the number of translations needed. That is, you would > see the equivalent of "Italy", and "United States (Los Angeles)" -- only in > the latter case do we need translations for the cities. > > 3. Translators can optionally add other variations: daylight (summer) > time, standard (winter) time, and generic time, both abbreviated and long. > > 4. These choices percolate out to clients of CLDR: Google, IBM, > Apple, Adobe, and many others. > > Mark > > On 7/10/07,* Olson, Arthur David (NIH/NCI) [E]* > wrote: > > I'm forwarding this message from Vincent Untz, who is not on the time zone > mailing list. > > Those of you who are on the time zone mailing list should direct replies > appropriately. > > --ado > > -----Original Message----- > From: Vincent Untz [mailto: vuntz at gnome.org] > Sent: Tuesday, July 10, 2007 1:24 PM > To: tz at lecserver.nci.nih.gov > Subject: Localization of timezones from zone.tab > > Hi, > > [please keep me cc'ed since I'm not subscribed to this list] > > I know that, at least in GNOME, there are now three places where we > > parse zone.tab to get a list of timezones supported by the OS. I suppose > other projects are also doing this. This list is then presented to the > user to let him choose the timezone. > > The problem here is that we let the user choose strings which look like > "Antarctica/South_Pole". This is not really good for > non-english-speaking people ;-) > > Of course, we can add all the timezones to our list of strings to > translate, but this means all projects needing to do so will duplicate > this work and the translations. > > I'd like the tz database to ship translations in po files. This would > imply the following: > > + create a small script to generate a POT file from zone.tab (easy) > + submit the POT file to the translation project [1] (or any other > > place that helps with translation) > > + add the po files for translation to the tz database > + choose a gettext domain > > (Of course, I'm quite probably forgetting about a step :-)) > > I've seen that this topic has been discussed before [2], but the > proposition there was really more ambitious, so I'm hoping a simple > approach would be welcomed. > > What do you think? > > Thanks, > > [1] http://translationproject.org/ > [2] http://osdir.com/ml/time.tz/2004-09/msg00000.html > > Vincent > > -- > Les gens heureux ne sont pas press?s. > > > > > -- > Mark > > > > > > -- > Mark > > > -- Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/tz/attachments/20070710/0606e527/attachment-0001.html From Paul.Schauble at ticketmaster.com Tue Jul 10 22:12:44 2007 From: Paul.Schauble at ticketmaster.com (Paul Schauble) Date: Tue, 10 Jul 2007 15:12:44 -0700 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: References: Message-ID: <0165EECEBB4CF745ACF095E1176B03EA12C7FFE3@SUNCA-EXB-AV1.ticketmaster.corp> I suggested some time ago that zones should be named according to the authority that declared the zone. This would often result in country names or country name (subdivision). But it would also clearly identify things like "Navajo Time" as such rather than lumping this in with "Denver". I think this gives a more stable system that largest city. It completely avoids the issues of what is a city. And it avoids changing zone names when city population changes. ++PLS -----Original Message----- From: rlaw at nc.rr.com [mailto:rlaw at nc.rr.com] Sent: Tuesday, July 10, 2007 11:38 AM To: tz at lecserver.nci.nih.gov Subject: Re: Vietnam: Saigon is deprecated, should use capital Hanoi > As the term city is ambiguous, the standard is ambiguous and > inconsistent anyway. How can we put an end to the incessant disputation over time zone identifiers? If we go by metropolitan area populations, someone will say we should go by central city populations. If we use any criterion that chooses Hanoi, someone will say Ho Chi Minh City is more important; but others will argue that the capital city is always more important. We must bear in mind that these are only supposed to be identifiers. Conceptually, we could be using WT/QAF just as well as Europe/Rome. It was merely for the convenience of developers that mnemonic names were chosen. But it is the responsibility of a user interface, not of the tz database, to translate the time zone identifiers into user-friendly names. The volunteer maintainers of the tz database have plenty of work to do, just to keep it up to date. If their job description is expanded to include making sure that the definitions of cities are consistent, providing universally acceptable names and abbreviations for time zones, or enabling localization by giving the translations of city, country, and time zone names into an arbitrary number of languages, I believe that puts too much on their plate. Presumably the CLDR addresses localization issues. Whoever maintains the CLDR has undertaken responsibility for interpreting the identifiers into human-readable form. Identifiers should be stable, too. True, by using backward-compatibility links, we can minimize the disruption caused by changing an identifier. Still, any kind of change has its cost, and a lot of the cost is hidden. We don't know how many people have used "Europe/Rome" somewhere in their code or nomenclature or documentation, and would deem it necessary to change the string if the primary name of that time zone changed to "Europe/Milan". (Of course, some changes are unavoidable, when time zones split.) My suggestion would be to state boldly in the documentation, "Time zone identifiers are arbitrary. Although they look as if they have a geographic interpretation, there is no guarantee that they do, or will continue to in the future. They should not be displayed directly to end users." Then, if possible, there should be some discussion of how to display time zone information to users. If we get GIS files for time zone boundaries, that will be a big help. Maintaining the boundary files would fall within the purview of the tz mailing list. Gwillim Law From mark.davis at icu-project.org Tue Jul 10 23:45:53 2007 From: mark.davis at icu-project.org (Mark Davis) Date: Tue, 10 Jul 2007 16:45:53 -0700 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: <0165EECEBB4CF745ACF095E1176B03EA12C7FFE3@SUNCA-EXB-AV1.ticketmaster.corp> References: <0165EECEBB4CF745ACF095E1176B03EA12C7FFE3@SUNCA-EXB-AV1.ticketmaster.corp> Message-ID: <30b660a20707101645g4334f272k2444a65ecb0c10d3@mail.gmail.com> I agree with Gwillim Law; these are just identifiers. As far as I'm concerned, the best strategy would be 1. Never change remove or change what is in zone.tab. 2. Only add a new identifier to zone.tab if a zone splits. 3. For such a new identifier, pick the largest city in the new zone according to some reasonable authority (eg National Geographic Atlas of the World). Since it is just an identifier, don't worry about whether or not it includes metropolitan areas or how; don't worry about whether the authority is the best possible one or not. 4. Make sure that last field is unique, eg don't have America/United_States/San_Jose if you have America/Costa_Rica/San_Jose. If it would not be unique, choose a different identifier for zone.tab, or have some minor modification (San_Jose2) 5. Add aliases (links) where useful for clarification. Short of that, the current policies are reasonable, although it forces other parties (like CLDR) to impose additional measures for stability of identifiers. Mark On 7/10/07, Paul Schauble wrote: > > I suggested some time ago that zones should be named according to the > authority that declared the zone. This would often result in country > names or country name (subdivision). But it would also clearly identify > things like "Navajo Time" as such rather than lumping this in with > "Denver". > > I think this gives a more stable system that largest city. It completely > avoids the issues of what is a city. And it avoids changing zone names > when city population changes. > > ++PLS > > -----Original Message----- > From: rlaw at nc.rr.com [mailto:rlaw at nc.rr.com] > Sent: Tuesday, July 10, 2007 11:38 AM > To: tz at lecserver.nci.nih.gov > Subject: Re: Vietnam: Saigon is deprecated, should use capital Hanoi > > > As the term city is ambiguous, the standard is ambiguous and > > inconsistent anyway. > > How can we put an end to the incessant disputation over time zone > identifiers? If we go by metropolitan area populations, someone will > say we should go by central city populations. If we use any criterion > that chooses Hanoi, someone will say Ho Chi Minh City is more important; > but others will argue that the capital city is always more important. > > We must bear in mind that these are only supposed to be identifiers. > Conceptually, we could be using WT/QAF just as well as Europe/Rome. It > was merely for the convenience of developers that mnemonic names were > chosen. But it is the responsibility of a user interface, not of the tz > database, to translate the time zone identifiers into user-friendly > names. > > The volunteer maintainers of the tz database have plenty of work to do, > just to keep it up to date. If their job description is expanded to > include making sure that the definitions of cities are consistent, > providing universally acceptable names and abbreviations for time zones, > or enabling localization by giving the translations of city, country, > and time zone names into an arbitrary number of languages, I believe > that puts too much on their plate. > > Presumably the CLDR addresses localization issues. Whoever maintains > the CLDR has undertaken responsibility for interpreting the identifiers > into human-readable form. > > Identifiers should be stable, too. True, by using > backward-compatibility links, we can minimize the disruption caused by > changing an identifier. Still, any kind of change has its cost, and a > lot of the cost is hidden. We don't know how many people have used > "Europe/Rome" somewhere in their code or nomenclature or documentation, > and would deem it necessary to change the string if the primary name of > that time zone changed to "Europe/Milan". (Of course, some changes are > unavoidable, when time zones split.) > > My suggestion would be to state boldly in the documentation, "Time zone > identifiers are arbitrary. Although they look as if they have a > geographic interpretation, there is no guarantee that they do, or will > continue to in the future. They should not be displayed directly to end > users." Then, if possible, there should be some discussion of how to > display time zone information to users. If we get GIS files for time > zone boundaries, that will be a big help. Maintaining the boundary > files would fall within the purview of the tz mailing list. > > Gwillim Law > -- Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/tz/attachments/20070710/4b942b11/attachment-0001.html From bernard.desruisseaux at oracle.com Wed Jul 11 01:40:16 2007 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Tue, 10 Jul 2007 21:40:16 -0400 Subject: FW: Time Zone mapping --> Windows ??? In-Reply-To: References: Message-ID: <46943500.6020407@oracle.com> Mapping from Windows Time Zone Names to Olson Time Zone Keys http://www.chronos-st.org/Windows-to-Olson.html Unicode CLDR Version 1.5-draft: Windows --> Tzid http://unicode.org/cldr/data/diff/supplemental/windows_tzid.html Olson, Arthur David (NIH/NCI) [E] wrote: > I'm forwarding this message from Boris Lang, who is not on the time zone mailing list. > > Those of you who are on the time zone mailing list should direct replies appropriately. > > --ado > > -----Original Message----- > From: BORIS LANG [mailto:BORIS.LANG at MEMO.IKEA.COM] > Sent: Tuesday, July 10, 2007 8:55 AM > To: tz at lecserver.nci.nih.gov > Subject: Time Zone mapping --> Windows ??? > > --- Received from IKEA4.BRLG +49 6122 5858276 07-07-10 14.56 -------------------------------------- > > Hi, > > we are working on the implementation of time zone information into an application using the tz database. TZ data names > will be our main type but we also need to do a mapping to the time zone names used in windows. > > i.e. Europe/Berlin (tzd) --> Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna (Windows) > > > The problem is that I can?t find a complete list that contains the mapping from tz database to windows. > > Can somebody please help us? Is there already such a list existing? > > Best regards > Boris Lang > > > ------ > IKEA IT Germany GmbH > Am Wandersmann 2-4 > 65719 Hofheim-Wallau > > Sitz M?nchen HR B 79392, Amtsgericht M?nchen > Gesch?ftsf?hrer: Manfred Godlewski, G?ran Sj?strand, Ola Troedsson > > ---- 07-07-10 14.56 ---- Sent to --------------------------------------------------------------------------------- > -> tz at elsie.nci.nih.gov From autarch at urth.org Wed Jul 11 04:21:06 2007 From: autarch at urth.org (Dave Rolsky) Date: Tue, 10 Jul 2007 23:21:06 -0500 (CDT) Subject: FW: Time Zone mapping --> Windows ??? In-Reply-To: <46943500.6020407@oracle.com> References: <46943500.6020407@oracle.com> Message-ID: On Tue, 10 Jul 2007, Bernard Desruisseaux wrote: > Mapping from Windows Time Zone Names to Olson Time Zone Keys > http://www.chronos-st.org/Windows-to-Olson.html Unfortunately, these names are localized in Windows, so this mapping only works for English language Windows versions. I'm using this mapping in a Perl module I wrote (DateTime::TimeZone - http://search.cpan.org/dist/DateTime-TimeZone/) and got a bug report from a user regarding this issue. -dave /*=================================================== VegGuide.Org www.BookIRead.com Your guide to all that's veg. My book blog ===================================================*/ From kre at munnari.OZ.AU Wed Jul 11 13:15:33 2007 From: kre at munnari.OZ.AU (Robert Elz) Date: Wed, 11 Jul 2007 20:15:33 +0700 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: <0165EECEBB4CF745ACF095E1176B03EA12C7FFE3@SUNCA-EXB-AV1.ticketmaster.corp> References: <0165EECEBB4CF745ACF095E1176B03EA12C7FFE3@SUNCA-EXB-AV1.ticketmaster.corp> Message-ID: <19132.1184159733@munnari.OZ.AU> Date: Tue, 10 Jul 2007 15:12:44 -0700 From: "Paul Schauble" Message-ID: <0165EECEBB4CF745ACF095E1176B03EA12C7FFE3 at SUNCA-EXB-AV1.ticketmaster.corp> | I suggested some time ago that zones should be named according to the | authority that declared the zone. Does that work in the US, where all zones are under the authority of the Dept of Transport (or something like that) - you'd still need additional names to determine just which of the multiple different zones they meant - and even then dealing with historical names would mean that you can't just use the names the relevant dept assign, as they don't usually bother to provide names for things which are no longer current, but we need them. Just stop arguing about this silly issue - it doesn't really matter what the zones are called. City names are a fairly good choice, as it is very unlikely that a single city doesn't have a single timezone history and rules. Further, the biggest city is a good choice, as it is unlikely that people aren't going to know if the local time is different than whatever is the biggest regional city. Definitions of cities don't need to be precise - nothing really important depends upon the results - we aren't specifying the time that applies in that city, just using its name as the label for a time zone (where any unique label would do just as well - which is why when the city that would normally be selected doesn't have a unique enough name, we just pick another.) A "city" is just what some outsider would consider to be that city, so as far as I'm concerned, if I arrive at Heathrowe (or Gatwick) I'm in London. On the other hand, if I'm in Essen, I'm in Essen, the city, Ruhrgebiet, or Rhein-Ruhr is a region name, not a city, so they're not really options for us to choose. Stability is not too much of an issue either, nothing depends upon "biggest" that's just a convenient way to (try to) pick cities without having these endless absurd arguments. That's why "most important" is never going to work - all that would ever do is cause arguments, never settle any. Once picked, we retain the same city name, even if something else becomes bigger - at least until it is clear that some other city is substantially larger and going to remain that way. Whether we should be using Rome or Milan in Italy, I'll leave to someone who understands Italian geography and politics - if it should be Milan, we can just fix it (and of course, keep Rome as an alias). That is, if everyone who knows enough to have an opinion on this (which certainly excludes me) agrees that Milan is substantially bigger than Rome, and that isn't likely to change. If the issue is debatable enough for anyone to argue (reasonably) about, then we should just stick with what we have. The same for Calcutta/Mumbai and Karachi/Lahor. We already had the Beijing/Shanghai discussion, and while it may alter in the future, things don't yet seem clear cut enough to make a change there. kre From Masayoshi.Okutsu at Sun.COM Wed Jul 11 15:03:38 2007 From: Masayoshi.Okutsu at Sun.COM (Masayoshi Okutsu) Date: Thu, 12 Jul 2007 00:03:38 +0900 Subject: FW: Time Zone mapping --> Windows ??? In-Reply-To: References: <46943500.6020407@oracle.com> Message-ID: <4694F14A.4020907@sun.com> On 7/11/2007 1:21 PM, Dave Rolsky wrote: > On Tue, 10 Jul 2007, Bernard Desruisseaux wrote: > >> Mapping from Windows Time Zone Names to Olson Time Zone Keys >> http://www.chronos-st.org/Windows-to-Olson.html > > Unfortunately, these names are localized in Windows, so this mapping > only works for English language Windows versions. I'm using this > mapping in a Perl module I wrote (DateTime::TimeZone - > http://search.cpan.org/dist/DateTime-TimeZone/) and got a bug report > from a user regarding this issue. In case you are tring to find out the tzid for the current Windows time zone... The time zone names from GetTimeZoneInformation() are localized. You'd need to find the "Time Zones" registry entry that matches the GetTimeZoneInformation() return value. Then, its registry key name can be used to look up a mapping table. However, different Windows versions use different key names. And some old localized Windows (NT/2000) have localized key names. In that case Java uses the mapID value which is not in Windows XP with a time zone patch and Vista. IIRC, key name "GMT" is used for different time zones in different Windows versions. It's a mess if you try to map Windows time zones to tzids... Masayoshi From tkpublic at timklein.fastmail.fm Wed Jul 11 23:15:36 2007 From: tkpublic at timklein.fastmail.fm (Tim Klein) Date: Wed, 11 Jul 2007 18:15:36 -0500 Subject: Is there a list of "current" time zones? In-Reply-To: References: Message-ID: Thank you, to those who helped me with this question! Especially big thanks to the ICU project folks (icu-project.org), whose "metazones" work got us most of the way to the data we needed. Tim From vuntz at gnome.org Thu Jul 12 14:09:19 2007 From: vuntz at gnome.org (Vincent Untz) Date: Thu, 12 Jul 2007 16:09:19 +0200 Subject: Localization of timezones from zone.tab In-Reply-To: References: Message-ID: <20070712140919.GP30640@vuntz.net> Le mardi 10 juillet 2007, ? 13:34 -0400, Andy Lipscomb a ?crit : > Currently, the main effort to localize time-zone information is in the Common Language Data Repository (I think that's what it's called, I know it's CLDR for initials), hosted at http://www.unicode.org/cldr; for each zone, there is the option to localize two names (DST and standard), the initials for those names, and the example city. Thanks for the pointer. I didn't know that CLDR contains this. That's cool :-) Vincent -- Les gens heureux ne sont pas press?s. From clive at demon.net Fri Jul 13 09:05:52 2007 From: clive at demon.net (Clive D.W. Feather) Date: Fri, 13 Jul 2007 10:05:52 +0100 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: <30b660a20707101645g4334f272k2444a65ecb0c10d3@mail.gmail.com> References: <0165EECEBB4CF745ACF095E1176B03EA12C7FFE3@SUNCA-EXB-AV1.ticketmaster.corp> <30b660a20707101645g4334f272k2444a65ecb0c10d3@mail.gmail.com> Message-ID: <20070713090552.GF21582@finch-staff-1.thus.net> Mark Davis said: > I agree with Gwillim Law; these are just identifiers. As far as I'm > concerned, the best strategy would be > > 1. Never change remove or change what is in zone.tab. > 2. Only add a new identifier to zone.tab if a zone splits. I would certainly agree with those. Stability is more important than always providing the name of the current largest city. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | From clive at demon.net Fri Jul 13 09:17:50 2007 From: clive at demon.net (Clive D.W. Feather) Date: Fri, 13 Jul 2007 10:17:50 +0100 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: References: Message-ID: <20070713091750.GG21582@finch-staff-1.thus.net> Claus F?rber said: >> Not if it's London as in the Greater London Authority (or, historically, >> the Greater London Council, the London County Council, etc.), as opposed >> to the City of London which has been only a small part of the geography >> and government of the greater city for centuries. > The GLA is a super-city authority, covering multiple cities such as the > City of London, the City of Westminster, etc. Well, that just proves my > point that the term "city" introduces ambiguity. The term "city" has at least three meanings within the UK: (1) [the legal definition] A local authority area granted city status by the crown. The LA may be a District, a Borough, or a Parish. (2) [the pub lawyer's definition] A conurbation containing a cathedral. (3) [colloquial] A large conurbation. London is a city under the second and third definitions, and a local authority area containing two cities under the first. But so what? Every country has its own concept of what a "city" is and how it differs from a town. The colloquial one is probably better *FOR THIS PURPOSE* than either of the other two. > It's simply inconsistent to treat Greater London as a "city", which is > made up of multiple municipalities like the City of London, Westminster, > etc., They aren't municipalities, they're boroughs. And Birmingham is equally split up into wards. So what? > It's also inconsistent to treat Greater London as a "city" and not > Greater Milan (7 million), which would be substantially larger than > Rome or Greater Rome (2.5 or 3.3 million). Does "Greater Milan" have a single governmental authority? -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | From kre at munnari.OZ.AU Fri Jul 13 13:59:11 2007 From: kre at munnari.OZ.AU (Robert Elz) Date: Fri, 13 Jul 2007 20:59:11 +0700 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: <20070713091750.GG21582@finch-staff-1.thus.net> References: <20070713091750.GG21582@finch-staff-1.thus.net> Message-ID: <16339.1184335151@munnari.OZ.AU> Date: Fri, 13 Jul 2007 10:17:50 +0100 From: "Clive D.W. Feather" Message-ID: <20070713091750.GG21582 at finch-staff-1.thus.net> | But so what? Every country has its own concept of what a "city" is and how | it differs from a town. Actually, for us, that distinction isn't relevant either. We use "city" to just mean "local population centre" - whether that's a village, town or "city" in some other nomenclature doesn't matter. All that matters is that it is a location where people live closely enough together that they're all going to set their clocks to the same time. (If some area that people might like to call a city, such as the Coolangatta/Tweed Heads on the Qld/NSW border in Aust, doesn't have the "same time" property, then it is useless for our purposes, and doesn't warrang further consideration, unless perhaps one or more of its time zones is uniquely used in that area) | Does "Greater Milan" have a single governmental authority? That doesn't matter either - the Sydney/Blacktown example would fail if that were the test. The local govt authority for Sydney covers a fairly small area, and while the population there during working hours is fairly high, not very many actually live there, there are plenty of municipalities (with their own local govt) that would have larger populations than the city of Sydney (according to municipal boundaries). Whether Blacktown is the biggest of them or not I have no idea, but it might be. But that's not the Sydney that almost anyone thinks of - even people who live in Blacktown would tell you that they're from Sydney if you ask them, not from Blacktown - not unless you ask "where in Sydney?". Sydney for our purposes includes all its suburbs, and perhaps even (these days) the Illawarra region (Wollongong etc) and maybe even Newcastle (if it doesn't it probably will within a few years). kre From eggert at CS.UCLA.EDU Wed Jul 18 07:26:17 2007 From: eggert at CS.UCLA.EDU (Paul Eggert) Date: Wed, 18 Jul 2007 00:26:17 -0700 Subject: FW: Does UTC+14 Still Exist? In-Reply-To: (Arthur David Olson's message of "Wed\, 27 Jun 2007 08\:20\:36 -0400") References: Message-ID: <87myxurx46.fsf@penguin.cs.ucla.edu> > From: Robert Chapin [mailto:tz at info-svc.com] > Sent: Tuesday, June 26, 2007 10:47 PM > > The latest CIA map doesn't have the UTC+14 time zone on it.. > > https://www.cia.gov/library/publications/the-world-factbook/reference_maps/pdf/time_zones.pdf The previous (2005) CIA map didn't either; see . Perhaps news travels slowly to the CIA? From eggert at CS.UCLA.EDU Wed Jul 18 07:37:28 2007 From: eggert at CS.UCLA.EDU (Paul Eggert) Date: Wed, 18 Jul 2007 00:37:28 -0700 Subject: Geographical boundaries for the continental US tz zones In-Reply-To: <4687DF3F.2080005@adobe.com> (Eric Muller's message of "Sun\, 01 Jul 2007 10\:07\:11 -0700") References: <465E634D.2080301@adobe.com> <4687DF3F.2080005@adobe.com> Message-ID: <87ir8irwlj.fsf@penguin.cs.ucla.edu> Eric Muller writes: > I have completed a first version of a map of the TZ timezones in the US. > It is available as a shapefile at . Thanks. Does the following HTML summarize it accurately?
  • A map of the TZ timezones in the US contains a shapefile of the tz regions in the US.
    • From eggert at CS.UCLA.EDU Wed Jul 18 07:41:28 2007 From: eggert at CS.UCLA.EDU (Paul Eggert) Date: Wed, 18 Jul 2007 00:41:28 -0700 Subject: Geographical boundaries for the continental US tz zones In-Reply-To: (Jesper Norgaard Welen's message of "Sun\, 01 Jul 2007 17\:32\:22 -0500") References: Message-ID: <87ejj6rwev.fsf@penguin.cs.ucla.edu> Jesper Norgaard Welen tried to send the following email to the list on July 1, but apparently didn't get through. I am enclosing it in the hopes that it does get through this time. From: Jesper Norgaard Welen [mailto:jnorgard at prodigy.net.mx] Sent: Domingo, 01 de Julio de 2007 16:15 To: 'tz at elsie.nci.nih.gov' Cc: 'emuller at adobe.com' Subject: RE: Geographical boundaries for the continental US tz zones Hello, Eric Muller I send my comments to your US timezone map directly to the TZ list since I think it could be of common interest in the list and also to urge members to send comments where appropriate. My newest map for World Time Explorer you can download from http://worldtimeexplorer.com/tztables.zip * Navajo/Hopi reservations There is an important Hopi population that you have not included around Latitude 36.14 Longitude -109.40 that I would recommend you to include (see WTE map) * Nevada on Idaho time The city Jackpot in Nevada (and several others like Owyhee and Mountain city) are on Idaho south time, or Denver time if you will. I have included it in a 25 km broad strip of northern Elko county, however just based on common sense when there were cities 12 km below the border that were on Denver time, and I would not expect their time to stop 100 meters outside the city boundary, but note that it is arbitrary, and quite possibly not quite 25 km. Jackpot itself is quite close to the border to Idaho. * Idaho county split (Idaho state) I have a northern and southern part of Idaho county, which I got from another timezone map (possibly Manifold map). This indicates that the southern part of Idaho county is on America/Boise time while the northern part is on America/Los_Angeles. Note that this is *not* documented in the tz database - I am still a bit ambivalent which one to believe. If you want pure tz database functionality, the timezone border should be a little further south. * Alaska I have the same doubts as you. However, I have implemented a solution, however arbitrary it is, seems much better than just putting Juneau for all of Alaska. The Nome area is small, while most of northwestern Alaska is set to Anchorage time. Then there is a Yakutat area and a Juneau area. They are all based on counties in this area. Comments are welcome. * America/Kentucky/Louisville This city belongs to Jefferson county of Kentucky, so I just assumed that this would comprise the Louisville timezone - however tz database needs to describe this - and include more counties if there are more. It just states the vague "part of Kentucky". * Sioux county North Dakota Tz database states "part of Sioux county" and that is exactly what you have included, splitting it around Latitude 46 Longitude -101.34. Where did you get shis from? I have included all Sioux county being on same time, but that most be wrong. * Cherry county Nebraska I see you have a different, more detailed split of Cherry county than mine. Where did you get this from? * Morgan county, Tennessee I recently discovered that this county is on CST/CDT, and included this in the western part of Tennesse. It's around Latitude 36.07 Longitude -84.56 * Alabama Note that (parts of) Chambers, Lee and Russell counties should be on America/New_York time, not on America/Chicago time. * Culberson county, Texas Note that the parts of this county including Nickel creek and Pine Springs are on America/Denver time. Regards, - Jesper N?rgaard Welen -----Original Message----- From: Eric Muller [mailto:emuller at adobe.com] Sent: Domingo, 01 de Julio de 2007 12:07 To: tz at lecserver.nci.nih.gov Subject: Re: Geographical boundaries for the continental US tz zones I have completed a first version of a map of the TZ timezones in the US. It is available as a shapefile at . Comments welcome, Eric. From eggert at CS.UCLA.EDU Wed Jul 18 07:46:19 2007 From: eggert at CS.UCLA.EDU (Paul Eggert) Date: Wed, 18 Jul 2007 00:46:19 -0700 Subject: TimeZones and international waters In-Reply-To: (Christina Lawrence's message of "Sun\, 1 Jul 2007 13\:38\:00 -0500") References: Message-ID: <87abturw6s.fsf@penguin.cs.ucla.edu> "Christina Lawrence" writes: > What distance from shore defines "the territorial waters of any nation"? > Is it nation specific, or an internationally recognized distance from > shore? Sorry, but (like anything involving lawyers :-) it's complicated. Please see for some details. I'll add that URL too, in my next proposed patch. From eggert at CS.UCLA.EDU Wed Jul 18 07:56:19 2007 From: eggert at CS.UCLA.EDU (Paul Eggert) Date: Wed, 18 Jul 2007 00:56:19 -0700 Subject: Daviess, Dubois, Knox, Martin and Pike counties jump thru 1 more hoop Message-ID: <87644irvq4.fsf@penguin.cs.ucla.edu> The DOT yesterday announced a proposed rule that would move the 132,000 residents of Daviess, Dubois, Knox, Martin and Pike counties in Indiana back to Eastern time, effective November 4 (when DST ends this year). The proposed rule has a 30-day public comment period, and then must be approved by the DOT to become final. See the AP article on this subject at . From rlaw at nc.rr.com Wed Jul 18 16:07:45 2007 From: rlaw at nc.rr.com (rlaw at nc.rr.com) Date: Wed, 18 Jul 2007 12:07:45 -0400 Subject: Geographical boundaries for the continental US tz zones Message-ID: ----- Original Message ----- From: Paul Eggert > I send my comments to your US timezone map directly to the TZ list > since I > think it could be of common interest in the list and also to urge > members to > send comments where appropriate. I've put all of my findings about the limits of U.S. time zones (past and present) online at http://www.statoids.com/tus.html. It's all verbal description. For example: > * Idaho county split (Idaho state) > I have a northern and southern part of Idaho county, which I got from > another timezone map (possibly Manifold map). This indicates that the > southern part of Idaho county is on America/Boise time while the > northernpart is on America/Los_Angeles. I have "Idaho county north of the Salmon River" on Pacific Time. > * Sioux county North Dakota > Tz database states "part of Sioux county" and that is exactly what > you have > included, splitting it around Latitude 46 Longitude -101.34. Where > did you > get shis from? I have included all Sioux county being on same time, > but that > most be wrong. I have "Sioux county west of ND route 31" on Mountain Time. Gwillim Law From hellosticky at gmail.com Fri Jul 20 20:36:29 2007 From: hellosticky at gmail.com (Kevin) Date: Fri, 20 Jul 2007 16:36:29 -0400 Subject: Olson tz database tests Message-ID: <6936856c0707201336m479b4476wf0768ad826151586@mail.gmail.com> Hi, is there an existing suite of tests (e.g. unit tests, regression tests, etc.) for the Olson time zone database (to ensure validity, completeness, etc.)? I'm more interested in the logic than the language, although I would prefer C/C++, C#, or Java. Thanks, Kevin From f.de.kruijf at hetnet.nl Sun Jul 22 19:37:53 2007 From: f.de.kruijf at hetnet.nl (Freek de Kruijf) Date: Sun, 22 Jul 2007 13:37:53 -0600 Subject: Timezone of America/Tegucigalpa is wrong Message-ID: <200707221337.54120.f.de.kruijf@hetnet.nl> L.S. The timezone of America/Tegucigalpa includes a Daylight Saving Time. This is wrong. See http://en.wikipedia.org/wiki/Honduras . It is only UTC-6. I can confirm this, while I am there. -- fr.gr. Freek de Kruijf From Susan.Johnson at kronos.com Mon Jul 23 12:37:44 2007 From: Susan.Johnson at kronos.com (Johnson, Susan) Date: Mon, 23 Jul 2007 08:37:44 -0400 Subject: More daylight savings in Australia In-Reply-To: <873b34r8v6.fsf@penguin.cs.ucla.edu> References: <873b34r8v6.fsf@penguin.cs.ucla.edu> Message-ID: <48DD08B024C1A84EA744B144A7ACFB41082AFFCD@exchg-j.KRONOS.COM> Folks, Do we have any official word on what will happen in Western/Southern Australia and when? My Australian office tells me that it now looks like South Australia, NSW, ACT, Victoria, and Tasmania DST changes will occur the first Sunday in April 2008 - instead of the first Sunday in October 2007. All changes are permanent except for South Australia, which will undergo a 'trial' change. --Sue Susan Johnson Manager, Customer Engineering Product Management Kronos Incorporated p: (978) 947-4342 f: (978) 367-5818 www.kronos.com Experts at Improving the Performance of People and Business? -----Original Message----- From: Paul Eggert [mailto:eggert at CS.UCLA.EDU] Sent: Friday, April 13, 2007 4:12 AM To: tz at lecserver.nci.nih.gov Subject: Re: More daylight savings in Australia "Eric Ulevik" writes: > http://www.news.com.au/story/0,23599,21549128-2,00.html Thanks for the heads-up. Today's Sydney Morning Herald reports that South Australia and the Northern Territory (!) may sign up later, but that Western Australia and Queensland will not be involved. Perhaps we should wait a bit to see who falls into line. Also, the SMH says only "it is believed" the dates are as you mentioned. http://www.smh.com.au/articles/2007/04/12/1175971265494.html This is currently listed as the #4 most-viewed article on the Sydney Morning Herald web site. A slow news day? -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 269.3.0/758 - Release Date: 4/12/2007 11:52 AM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.12/910 - Release Date: 7/21/2007 3:52 PM From olsona at dc37a.nci.nih.gov Mon Jul 23 13:37:08 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Mon, 23 Jul 2007 09:37:08 -0400 Subject: FW: Timezone of America/Tegucigalpa is wrong Message-ID: I'm forwarding this message from Freek de Kruijf, who was not on the time zone mailing list at the time it was sent. Freek has since been added. --ado -----Original Message----- From: Freek de Kruijf [mailto:f.de.kruijf at hetnet.nl] Sent: Sunday, July 22, 2007 3:38 To: tz at lecserver.nci.nih.gov Subject: Timezone of America/Tegucigalpa is wrong L.S. The timezone of America/Tegucigalpa includes a Daylight Saving Time. This is wrong. See http://en.wikipedia.org/wiki/Honduras . It is only UTC-6. I can confirm this, while I am there. -- fr.gr. Freek de Kruijf From olsona at dc37a.nci.nih.gov Mon Jul 23 13:38:09 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Mon, 23 Jul 2007 09:38:09 -0400 Subject: FW: More daylight savings in Australia Message-ID: I'm forwarding this message from Susan Johnson, who is on the time zone mailing list at a different address than the one shown below. --ado -----Original Message----- From: Johnson, Susan [mailto:Susan.Johnson at kronos.com] Sent: Monday, July 23, 2007 8:39 To: tz at lecserver.nci.nih.gov Subject: RE: More daylight savings in Australia Folks, Do we have any official word on what will happen in Western/Southern Australia and when? My Australian office tells me that it now looks like South Australia, NSW, ACT, Victoria, and Tasmania DST changes will occur the first Sunday in April 2008 - instead of the first Sunday in October 2007. All changes are permanent except for South Australia, which will undergo a 'trial' change. --Sue Susan Johnson Manager, Customer Engineering Product Management Kronos Incorporated p: (978) 947-4342 f: (978) 367-5818 www.kronos.com Experts at Improving the Performance of People and Business(tm) -----Original Message----- From: Paul Eggert [mailto:eggert at CS.UCLA.EDU] Sent: Friday, April 13, 2007 4:12 AM To: tz at lecserver.nci.nih.gov Subject: Re: More daylight savings in Australia "Eric Ulevik" writes: > http://www.news.com.au/story/0,23599,21549128-2,00.html Thanks for the heads-up. Today's Sydney Morning Herald reports that South Australia and the Northern Territory (!) may sign up later, but that Western Australia and Queensland will not be involved. Perhaps we should wait a bit to see who falls into line. Also, the SMH says only "it is believed" the dates are as you mentioned. http://www.smh.com.au/articles/2007/04/12/1175971265494.html This is currently listed as the #4 most-viewed article on the Sydney Morning Herald web site. A slow news day? -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 269.3.0/758 - Release Date: 4/12/2007 11:52 AM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.12/910 - Release Date: 7/21/2007 3:52 PM From olsona at dc37a.nci.nih.gov Mon Jul 23 15:34:10 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Mon, 23 Jul 2007 11:34:10 -0400 Subject: Olson tz database tests In-Reply-To: <6936856c0707201336m479b4476wf0768ad826151586@mail.gmail.com> References: <6936856c0707201336m479b4476wf0768ad826151586@mail.gmail.com> Message-ID: The only thing I've got is the shell script below (known as "zgress" locally). --ado #!/bin/sh # Accept the names of two time zone package source directories (A and B). # Do a "make install" from each directory to temporary directories. # Apply the created "zdump" programs to all the created binary data files: # the A zdump to the A data (yielding AA results) # the A zdump to the B data (yielding AB results) # the B zdump to the A data (yielding BA results) # the B zdump to the B data (yielding BB results) # Report on differences. O=`basename "$0"` case $# in 2) ;; *) echo "$O: usage is $O atzsourcedir btzsourcedir" 1>&2 exit 1 ;; esac T=/tmp/,zgress$$ trap 'rm -f -r $T*' 0 1 2 3 15 # Step 1: do "make"s for both the A and B versions for pass in a b do ( cd "$1"; make clean; make install TOPDIR=$T$pass ) || exit 1 shift done # Step 2: apply both the A and B zdumps to both the A and B data for prog in a b do for data in a b do zdump=$T$prog/etc/zdump zoneinfo=$T$data/etc/zoneinfo $zdump -v `find $zoneinfo ! -type d -print | sort` 2>&- | sed "s@$zoneinfo/@@" > $T$prog$data done done # Step 3: do comparisons ls -l $T[ab][ab] left=aa for right in ab ba bb do diff $T$left $T$right | sed "s/^/$left vs. $right:/" done From eggert at CS.UCLA.EDU Mon Jul 23 23:07:48 2007 From: eggert at CS.UCLA.EDU (Paul Eggert) Date: Mon, 23 Jul 2007 16:07:48 -0700 Subject: Timezone of America/Tegucigalpa is wrong In-Reply-To: (Arthur David Olson's message of "Mon\, 23 Jul 2007 09\:37\:08 -0400") References: Message-ID: <87tzrulnwb.fsf@penguin.cs.ucla.edu> > From: Freek de Kruijf [mailto:f.de.kruijf at hetnet.nl] > Sent: Sunday, July 22, 2007 3:38 > > The timezone of America/Tegucigalpa includes a Daylight Saving Time. > This is wrong. See http://en.wikipedia.org/wiki/Honduras . It is > only UTC-6. I can confirm this, while I am there. Thanks. No need to confirm it; the latest version of the tz database already has this. You can get it from . It reports that Honduras observed DST in 1987/1988 and in 2006 (only). From eggert at CS.UCLA.EDU Mon Jul 23 23:46:25 2007 From: eggert at CS.UCLA.EDU (Paul Eggert) Date: Mon, 23 Jul 2007 16:46:25 -0700 Subject: FW: More daylight savings in Australia In-Reply-To: (Arthur David Olson's message of "Mon\, 23 Jul 2007 09\:38\:09 -0400") References: Message-ID: <87ps2ilm3y.fsf@penguin.cs.ucla.edu> > From: Johnson, Susan [mailto:Susan.Johnson at kronos.com] > Sent: Monday, July 23, 2007 8:39 > > My Australian office tells me that it now looks like South Australia, > NSW, ACT, Victoria, and Tasmania DST changes will occur the first Sunday > in April 2008 - instead of the first Sunday in October 2007. All > changes are permanent except for South Australia, which will undergo a > 'trial' change. Yes, that matches my understanding as well. Here are some changes that I plan to put into my next proposed set. These aren't "official" yet (as if anything in tz were "official" :-) but should give you a heads-up. --- australasia 2007/05/07 14:46:15 2007.6 +++ australasia 2007/07/23 23:23:07 @@ -79,7 +79,7 @@ Zone Australia/Lindeman 9:55:56 - LMT 1 # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule AS 1971 1985 - Oct lastSun 2:00s 1:00 - Rule AS 1986 only - Oct 19 2:00s 1:00 - -Rule AS 1987 max - Oct lastSun 2:00s 1:00 - +Rule AS 1987 2007 - Oct lastSun 2:00s 1:00 - Rule AS 1972 only - Feb 27 2:00s 0 - Rule AS 1973 1985 - Mar Sun>=1 2:00s 0 - Rule AS 1986 1989 - Mar Sun>=15 2:00s 0 - @@ -90,7 +90,9 @@ Rule AS 1993 only - Mar Sun>=1 2:00s 0 - Rule AS 1994 only - Mar Sun>=18 2:00s 0 - Rule AS 1995 2005 - Mar lastSun 2:00s 0 - Rule AS 2006 only - Apr Sun>=1 2:00s 0 - -Rule AS 2007 max - Mar lastSun 2:00s 0 - +Rule AS 2007 only - Mar lastSun 2:00s 0 - +Rule AS 2008 max - Apr Sun>=1 2:00s 0 - +Rule AS 2008 max - Oct Sun>=1 2:00s 1:00 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Adelaide 9:14:20 - LMT 1895 Feb 9:00 - CST 1899 May @@ -121,7 +123,8 @@ Rule AT 1991 2005 - Mar lastSun 2:00s 0 Rule AT 2000 only - Aug lastSun 2:00s 1:00 - Rule AT 2001 max - Oct Sun>=1 2:00s 1:00 - Rule AT 2006 only - Apr Sun>=1 2:00s 0 - -Rule AT 2007 max - Mar lastSun 2:00s 0 - +Rule AT 2007 only - Mar lastSun 2:00s 0 - +Rule AT 2008 max - Apr Sun>=1 2:00s 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Hobart 9:49:16 - LMT 1895 Sep 10:00 - EST 1916 Oct 1 2:00 @@ -145,9 +148,11 @@ Rule AV 1988 1999 - Oct lastSun 2:00s 1: Rule AV 1991 1994 - Mar Sun>=1 2:00s 0 - Rule AV 1995 2005 - Mar lastSun 2:00s 0 - Rule AV 2000 only - Aug lastSun 2:00s 1:00 - -Rule AV 2001 max - Oct lastSun 2:00s 1:00 - +Rule AV 2001 2007 - Oct lastSun 2:00s 1:00 - Rule AV 2006 only - Apr Sun>=1 2:00s 0 - -Rule AV 2007 max - Mar lastSun 2:00s 0 - +Rule AV 2007 only - Mar lastSun 2:00s 0 - +Rule AV 2008 max - Apr Sun>=1 2:00s 0 - +Rule AV 2008 max - Oct Sun>=1 2:00s 1:00 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Melbourne 9:39:52 - LMT 1895 Feb 10:00 Aus EST 1971 @@ -166,9 +171,11 @@ Rule AN 1987 1999 - Oct lastSun 2:00s 1: Rule AN 1990 1995 - Mar Sun>=1 2:00s 0 - Rule AN 1996 2005 - Mar lastSun 2:00s 0 - Rule AN 2000 only - Aug lastSun 2:00s 1:00 - -Rule AN 2001 max - Oct lastSun 2:00s 1:00 - +Rule AN 2001 2007 - Oct lastSun 2:00s 1:00 - Rule AN 2006 only - Apr Sun>=1 2:00s 0 - -Rule AN 2007 max - Mar lastSun 2:00s 0 - +Rule AN 2007 only - Mar lastSun 2:00s 0 - +Rule AN 2008 max - Apr Sun>=1 2:00s 0 - +Rule AN 2008 max - Oct Sun>=1 2:00s 1:00 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Sydney 10:04:52 - LMT 1895 Feb 10:00 Aus EST 1971 @@ -191,9 +198,11 @@ Rule LH 1987 1999 - Oct lastSun 2:00 0:3 Rule LH 1990 1995 - Mar Sun>=1 2:00 0 - Rule LH 1996 2005 - Mar lastSun 2:00 0 - Rule LH 2000 only - Aug lastSun 2:00 0:30 - -Rule LH 2001 max - Oct lastSun 2:00 0:30 - +Rule LH 2001 2007 - Oct lastSun 2:00 0:30 - Rule LH 2006 only - Apr Sun>=1 2:00 0 - -Rule LH 2007 max - Mar lastSun 2:00 0 - +Rule LH 2007 only - Mar lastSun 2:00 0 - +Rule LH 2008 max - Apr Sun>=1 2:00 0 - +Rule LH 2008 max - Oct Sun>=1 2:00 0:30 - Zone Australia/Lord_Howe 10:36:20 - LMT 1895 Feb 10:00 - EST 1981 Mar 10:30 LH LHST From cppcraze at gmail.com Fri Jul 27 04:55:30 2007 From: cppcraze at gmail.com (Martin Dong) Date: Fri, 27 Jul 2007 12:55:30 +0800 Subject: How to support such capabilites based on current Olson Time Zone implementation Message-ID: Dear All in this maillist, We have been investigating the feasibility of migrating Olson Time Zone Database to our system. Given that our system is Linux-based, we can just use tzcode implementation or Glibc functions because Glibc has adopted Olson implementation to some extent. But according to our basic and existing requirements, I have met some problems that I think are hard for me: - How to get the local time of different region or city at the same time? The basic requirement is to display the local time of different region or city at the same time. After some study of Olson implementation, I knew function "localtime" will handle everything, parsing tzfile and doing the conversion from utc to local time. The correct local time can be gotten through a simple invocation to "localtime". But "localtime" assumes the Sytem Local Time Zone is set in environmental variable "TZ" or from the Standard TimeZone file "/etc/localtime" if "TZ" is not defined in the process. In this case, how can a caller get the local time of some city which is not the System Local Time Zone? It seems we must change "TZ" or the Standard TimeZone file before calling "localtime" to get another city's local time because "localtime" doesn't take such an argument that can let caller specify a time zone, which means "localtime" can return the local time related to either the System Local Time Zone or the time zone user specifies. Although I know there're so many applications which already integrates the Olson Database and they have realized my above requirement "display multiple local time at the same time", I don't know how they make it. - How to get the notification of DST status change as time elaspes? This problem is out of our another requirement that we need to inform other components in our system of the DST status change in various conditions, such as changing time may lead to DST change, changing local time zone may lead to DST change, and as time elapsing, etc. The former two behaviors are user-active ones, we can track the change easily, but the problem is the last one, it's the system automatic behavior, our of the control of user. In this case, the system needs some CALLBACK ability to capture this change and further broadcast it. For our system, there's an Alarm Server that can provide timer machinasm. We will parse our own time zone database and get the next nearest DST transition time and add it to Alarm Server, then when the timer is time out, Alarm Server will trigger a CALLBACK function to further process. But it seems Olson is lack of such capability. After thinking from another perpsective, if we can get the next nearest DST transition time through Olson Time Zone database, we can still utilize our current Alarm Server. But it's still a problem how to get the next nearest DST transition time through the current Olson implementation because all the implementation is hiden behind "localtime". In all the public functions, there's no such one which can support getting the DST transition time. I don't have any good idea in mind right now. Should I make some modification to Olson to add such capability, or other way i could go? I will very much appreciate if any of you can give me some hints about above problems. Thank you in advance. Best Regards, -Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/tz/attachments/20070727/145af57a/attachment-0001.html From jmorrow at sendwordnow.com Fri Jul 27 06:28:40 2007 From: jmorrow at sendwordnow.com (John B. Morrow) Date: Fri, 27 Jul 2007 02:28:40 -0400 Subject: Does zic currently compile time zone abbreviations correctly? Message-ID: <8C509380F5C1E64686251D030FA286E0A1DE40@LATSVIVEX01.sendwordnow.local> In the process of extracting time zone information from the zoneinfo database, I noticed that the abbreviation pointer break for quite a few time zones including Europe/London, Asia/Dubai, and quite a few others. The problem seems to be in the compiled time zone files so I spent some time looking at zic. What seems to be happening is that zic uses some criteria to determine of the abbreviation (and other info for types) is used and won't write it if it thinks it isn't needed. The problem is that it doesn't adjust the indexes (tt_abbrind) that reference those abbreviations, so they'll point to bad data or empty strings. My quick (and admittedly heavy handed fix) was to force zic to write all of the abbreviations, whether they are necessary or not. If this really is a problem, it should probably be fixed at some point. Please note that the data in our fairly recently updated Linux server has abbreviations that don't seem to work. If I'm missing something or there is some other way more correct way to reference the abbreviations, please let me know. I'm using tt_abbrind as per the tzfile man page and the tzcode2007f.tar.gz sources. John Morrow -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/tz/attachments/20070727/95cb552c/attachment-0001.html From olsona at dc37a.nci.nih.gov Fri Jul 27 15:20:33 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Fri, 27 Jul 2007 11:20:33 -0400 Subject: FW: Does zic currently compile time zone abbreviations correctly? Message-ID: I'm forwarding this message from John B. Morrow, who is not on the time zone mailing list. Those of you who are on the time zone mailing list should direct replies appropriately. --ado From: John B. Morrow [mailto:jmorrow at sendwordnow.com] Sent: Friday, July 27, 2007 2:29 AM To: tz at lecserver.nci.nih.gov Subject: Does zic currently compile time zone abbreviations correctly? In the process of extracting time zone information from the zoneinfo database, I noticed that the abbreviation pointer break for quite a few time zones including Europe/London, Asia/Dubai, and quite a few others.? The problem seems to be in the compiled time zone files so I spent some time looking at zic.? What seems to be happening is that zic uses some criteria to determine of the abbreviation (and other info for types) is used and won't write it if it thinks it isn't needed.? The problem is that it doesn't adjust the indexes (tt_abbrind) that reference those abbreviations, so they'll point to bad data or empty strings.? My quick (and admittedly heavy handed fix) was to force zic to write all of the abbreviations, whether they are necessary or not.? If this really is a problem, it should probably be fixed at some point.? Please note that the data in our fairly recently updated Linux server has abbreviations that don't seem to work. If I'm missing something or there is some other way more correct way to reference the abbreviations, please let me know.? I'm using tt_abbrind as per the tzfile man page and the tzcode2007f.tar.gz sources. John Morrow From olsona at dc37a.nci.nih.gov Fri Jul 27 15:29:03 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Fri, 27 Jul 2007 11:29:03 -0400 Subject: Does zic currently compile time zone abbreviations correctly? In-Reply-To: References: Message-ID: The typescript below seems to indicate that there's nothing amiss with Europe/London; do you get different results if you run "tzhead"? --ado Script started on Fri 27 Jul 2007 11:24:37 AM EDT lecserver$ cat tzhead.c #include "private.h" struct tzhead { char tzh_magic[4]; /* TZ_MAGIC */ char tzh_version[1]; /* '\0' or '2' as of 2005 */ char tzh_reserved[15]; /* reserved--must be zero */ char tzh_ttisgmtcnt[4]; /* coded number of trans. time flags */ char tzh_ttisstdcnt[4]; /* coded number of trans. time flags */ char tzh_leapcnt[4]; /* coded number of leap seconds */ char tzh_timecnt[4]; /* coded number of transition times */ char tzh_typecnt[4]; /* coded number of local time types */ char tzh_charcnt[4]; /* coded number of abbr. chars */ }; static char * progname; static long long detzcode64(codep) const char * const codep; { register long long result; register int i; result = (codep[0] & 0x80) ? ~0L : 0L; for (i = 0; i < 8; ++i) result = result * 256 + (codep[i] & 0xff); return result; } static long long detzcode(codep) const char * const codep; { register long result; register int i; result = (codep[0] & 0x80) ? ~0L : 0L; for (i = 0; i < 4; ++i) result = (result << 8) | (codep[i] & 0xff); return result; } static void wild2exit(cp, dp) { (void) fprintf(stderr, "%s: wild result %s %s\n", progname, cp, dp); exit(1); } static void handle(filename) char * filename; { FILE * fp; struct tzhead tzh; long long ll; char c; int i; int pass; long ttisgmtcnt; long ttisstdcnt; long leapcnt; long timecnt; long typecnt; long charcnt; char buf[8]; struct tm tm; fp = fopen(filename, "r"); if (fp == NULL) wild2exit("result opening", filename); for (pass = 1; pass <= 2; ++pass) { if (fread(&tzh, sizeof tzh, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tversion\t", filename); c = tzh.tzh_version[0]; if (isascii(c) && isprint(c)) (void) putchar(c); else (void) printf("\\%o", c); (void) putchar('\n'); ttisgmtcnt = detzcode(tzh.tzh_ttisgmtcnt); ttisstdcnt = detzcode(tzh.tzh_ttisstdcnt); leapcnt = detzcode(tzh.tzh_leapcnt); timecnt = detzcode(tzh.tzh_timecnt); typecnt = detzcode(tzh.tzh_typecnt); charcnt = detzcode(tzh.tzh_charcnt); (void) printf("%s\tttisgmtcnt\t%ld\n", filename, ttisgmtcnt); (void) printf("%s\tttisstdcnt\t%ld\n", filename, ttisstdcnt); (void) printf("%s\tleapcnt\t%ld\n", filename, leapcnt); (void) printf("%s\ttimecnt\t%ld\n", filename, timecnt); (void) printf("%s\ttypecnt\t%ld\n", filename, typecnt); (void) printf("%s\tcharcnt\t%ld\n", filename, charcnt); for (i = 0; i < timecnt; ++i) { if (fread(buf, pass * 4, 1, fp) != 1) wild2exit("result reading", filename); ll = (pass == 1) ? detzcode(buf) : detzcode64(buf); { time_t l; l = ll; tm = *gmtime(&l); } (void) printf("%s\ttime[%d]\t%lld\t%s", filename, i, ll, asctime(&tm)); } for (i = 0; i < timecnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\ttype[%d]\t%d\n", filename, i, buf[0]); } for (i = 0; i < typecnt; ++i) { long l; if (fread(buf, 4, 1, fp) != 1) wild2exit("result reading", filename); l = detzcode(buf); (void) printf("%s\ttype[%d].offset\t%ld\n", filename, i, l); if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\ttype[%d].isdst\t%ld\n", filename, i, buf[0]); if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\ttype[%d].abbrind\t%ld\n", filename, i, buf[0]); } for (i = 0; i < charcnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tabbr[%d]\t", filename, i); if (isascii(buf[0]) && isprint(buf[0])) (void) printf("%c", buf[0]); else if (buf[0] == '\0') (void) printf("\\0"); else (void) printf("\%03o", buf[0]); (void) printf("\n"); } for (i = 0; i < ttisstdcnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tisstd[%d]\t%d\n", filename, i, buf[0]); } for (i = 0; i < ttisgmtcnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tisgmt[%d]\t%d\n", filename, i, buf[0]); } if (tzh.tzh_version[0] != '2') break; } if (fclose(fp) != 0) { (void) fprintf(stderr, "%s: wild result closing %s\n", progname, filename); exit(1); } } int main(argc, argv) int argc; char * argv[]; { int i; progname = argv[0]; for (i = 1; i < argc; ++i) handle(argv[i]); exit(0); } lecserver$ make tzhead cc -DTZDIR=\"/usr/local/etc/zoneinfo\" tzhead.c -o tzhead lecserver$ tzhead tmp/etc/zoneinfo/Europe/London | grep abbr tmp/etc/zoneinfo/Europe/London type[0].abbrind 0 tmp/etc/zoneinfo/Europe/London type[1].abbrind 4 tmp/etc/zoneinfo/Europe/London type[2].abbrind 8 tmp/etc/zoneinfo/Europe/London type[3].abbrind 0 tmp/etc/zoneinfo/Europe/London type[4].abbrind 0 tmp/etc/zoneinfo/Europe/London type[5].abbrind 4 tmp/etc/zoneinfo/Europe/London type[6].abbrind 4 tmp/etc/zoneinfo/Europe/London abbr[0] B tmp/etc/zoneinfo/Europe/London abbr[1] S tmp/etc/zoneinfo/Europe/London abbr[2] T tmp/etc/zoneinfo/Europe/London abbr[3] \0 tmp/etc/zoneinfo/Europe/London abbr[4] G tmp/etc/zoneinfo/Europe/London abbr[5] M tmp/etc/zoneinfo/Europe/London abbr[6] T tmp/etc/zoneinfo/Europe/London abbr[7] \0 tmp/etc/zoneinfo/Europe/London abbr[8] B tmp/etc/zoneinfo/Europe/London abbr[9] D tmp/etc/zoneinfo/Europe/London abbr[10] S tmp/etc/zoneinfo/Europe/London abbr[11] T tmp/etc/zoneinfo/Europe/London abbr[12] \0 tmp/etc/zoneinfo/Europe/London type[0].abbrind 0 tmp/etc/zoneinfo/Europe/London type[1].abbrind 4 tmp/etc/zoneinfo/Europe/London type[2].abbrind 8 tmp/etc/zoneinfo/Europe/London type[3].abbrind 12 tmp/etc/zoneinfo/Europe/London type[4].abbrind 4 tmp/etc/zoneinfo/Europe/London type[5].abbrind 4 tmp/etc/zoneinfo/Europe/London type[6].abbrind 8 tmp/etc/zoneinfo/Europe/London type[7].abbrind 8 tmp/etc/zoneinfo/Europe/London abbr[0] L tmp/etc/zoneinfo/Europe/London abbr[1] M tmp/etc/zoneinfo/Europe/London abbr[2] T tmp/etc/zoneinfo/Europe/London abbr[3] \0 tmp/etc/zoneinfo/Europe/London abbr[4] B tmp/etc/zoneinfo/Europe/London abbr[5] S tmp/etc/zoneinfo/Europe/London abbr[6] T tmp/etc/zoneinfo/Europe/London abbr[7] \0 tmp/etc/zoneinfo/Europe/London abbr[8] G tmp/etc/zoneinfo/Europe/London abbr[9] M tmp/etc/zoneinfo/Europe/London abbr[10] T tmp/etc/zoneinfo/Europe/London abbr[11] \0 tmp/etc/zoneinfo/Europe/London abbr[12] B tmp/etc/zoneinfo/Europe/London abbr[13] D tmp/etc/zoneinfo/Europe/London abbr[14] S tmp/etc/zoneinfo/Europe/London abbr[15] T tmp/etc/zoneinfo/Europe/London abbr[16] \0 lecserver$ exit script done on Fri 27 Jul 2007 11:25:04 AM EDT From: John B. Morrow [mailto:jmorrow at sendwordnow.com] Sent: Friday, July 27, 2007 2:29 AM To: tz at lecserver.nci.nih.gov Subject: Does zic currently compile time zone abbreviations correctly? In the process of extracting time zone information from the zoneinfo database, I noticed that the abbreviation pointer break for quite a few time zones including Europe/London, Asia/Dubai, and quite a few others.? The problem seems to be in the compiled time zone files so I spent some time looking at zic.? What seems to be happening is that zic uses some criteria to determine of the abbreviation (and other info for types) is used and won't write it if it thinks it isn't needed.? The problem is that it doesn't adjust the indexes (tt_abbrind) that reference those abbreviations, so they'll point to bad data or empty strings.? My quick (and admittedly heavy handed fix) was to force zic to write all of the abbreviations, whether they are necessary or not.? If this really is a problem, it should probably be fixed at some point.? Please note that the data in our fairly recently updated Linux server has abbreviations that don't seem to work. If I'm missing something or there is some other way more correct way to reference the abbreviations, please let me know.? I'm using tt_abbrind as per the tzfile man page and the tzcode2007f.tar.gz sources. John Morrow From olsona at dc37a.nci.nih.gov Fri Jul 27 15:32:31 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Fri, 27 Jul 2007 11:32:31 -0400 Subject: FW: How to support such capabilites based on current Olson Time Zone implementation Message-ID: I'm forwarding this message from Martin Dong, who is not on the time zone mailing list. Those of you who are on the time zone mailing list should direct replies appropriately. --ado From: Martin Dong [mailto:cppcraze at gmail.com] Sent: Friday, July 27, 2007 12:56 AM To: tz at lecserver.nci.nih.gov Subject: How to support such capabilites based on current Olson Time Zone implementation Dear All in this maillist, ? We have been investigating the feasibility of migrating Olson Time Zone Database to our system. Given that our system is Linux-based, we can just use tzcode implementation or Glibc functions because Glibc has adopted Olson implementation to some extent. But according to our basic and?existing requirements, I have met some problems that I think are hard for me: * How to get the local time of different region or city at the same time? The basic requirement is to display the local time of different region or city at the same time. After some study of Olson implementation, I knew function "localtime" will handle everything, parsing tzfile and doing the conversion from utc to local time. The correct local?time can be gotten through a simple invocation to "localtime". But "localtime" assumes the Sytem Local Time Zone is set in environmental variable "TZ" or from the Standard TimeZone file "/etc/localtime" if "TZ" is not defined in the process. In this case, how can?a caller get the local?time of some city which is not the System Local Time Zone? It seems we must change "TZ" or the Standard TimeZone file before calling "localtime" to get another city's local time because "localtime" doesn't take such an argument that can let caller specify a time zone, which means "localtime" can return the local time related to either the System Local Time Zone or the time zone user specifies. ? Although I know there're so many applications?which already integrates the Olson Database and they have realized my?above requirement "display multiple local time at the same time", I don't know how they make it.? * How to get the notification of DST status change as time elaspes? This problem is out of our another requirement that we need to inform other components in our system of the DST status change in various conditions, such as changing time may lead to DST change, changing local time zone may lead to DST change, and as time elapsing, etc. The former two behaviors are user-active ones, we can track the change easily, but the problem is the last one, it's the system automatic behavior, our of the control of user. In this case, the system needs some CALLBACK ability to capture this change and further broadcast it. For our system, there's an Alarm Server that can provide timer machinasm. We will parse our own time zone database and get the next nearest DST transition time and add it to Alarm Server, then when the timer is time out, Alarm Server will trigger a CALLBACK function to further process. ? But it seems Olson is lack of such capability. After thinking from another perpsective, if we can get the next nearest DST transition time through Olson Time Zone database, we can still utilize our current Alarm Server. But it's still a problem how to get the next nearest DST transition time through the current Olson implementation because all the implementation is hiden behind "localtime". In all the public functions, there's no such one which can support getting the DST transition time. ? I don't have any good idea in mind right now. Should I make some modification to Olson to add such capability, or other way i could go? I will very much appreciate if any of you can give me some hints about above problems. Thank you in advance. ? Best Regards, ? -Martin From jmorrow at sendwordnow.com Fri Jul 27 16:18:58 2007 From: jmorrow at sendwordnow.com (John B. Morrow) Date: Fri, 27 Jul 2007 12:18:58 -0400 Subject: Does zic currently compile time zone abbreviations correctly? References: Message-ID: <8C509380F5C1E64686251D030FA286E0A1DF52@LATSVIVEX01.sendwordnow.local> This response and program was very helpful. Apparently I was missing the level of indirection that converted the type in the ttinfo into an abbrind to look up the abbreviation. For some time zones, that was fine and for others it wasn't. Now that I've added that additional level in, my program seems to be working correctly. Thank you for your quick response. John Morrow -----Original Message----- From: Olson, Arthur David (NIH/NCI) [E] [mailto:olsona at dc37a.nci.nih.gov] Sent: Friday, July 27, 2007 11:29 AM To: tz at elsie.nci.nih.gov Cc: John B. Morrow Subject: RE: Does zic currently compile time zone abbreviations correctly? The typescript below seems to indicate that there's nothing amiss with Europe/London; do you get different results if you run "tzhead"? --ado Script started on Fri 27 Jul 2007 11:24:37 AM EDT lecserver$ cat tzhead.c #include "private.h" struct tzhead { char tzh_magic[4]; /* TZ_MAGIC */ char tzh_version[1]; /* '\0' or '2' as of 2005 */ char tzh_reserved[15]; /* reserved--must be zero */ char tzh_ttisgmtcnt[4]; /* coded number of trans. time flags */ char tzh_ttisstdcnt[4]; /* coded number of trans. time flags */ char tzh_leapcnt[4]; /* coded number of leap seconds */ char tzh_timecnt[4]; /* coded number of transition times */ char tzh_typecnt[4]; /* coded number of local time types */ char tzh_charcnt[4]; /* coded number of abbr. chars */ }; static char * progname; static long long detzcode64(codep) const char * const codep; { register long long result; register int i; result = (codep[0] & 0x80) ? ~0L : 0L; for (i = 0; i < 8; ++i) result = result * 256 + (codep[i] & 0xff); return result; } static long long detzcode(codep) const char * const codep; { register long result; register int i; result = (codep[0] & 0x80) ? ~0L : 0L; for (i = 0; i < 4; ++i) result = (result << 8) | (codep[i] & 0xff); return result; } static void wild2exit(cp, dp) { (void) fprintf(stderr, "%s: wild result %s %s\n", progname, cp, dp); exit(1); } static void handle(filename) char * filename; { FILE * fp; struct tzhead tzh; long long ll; char c; int i; int pass; long ttisgmtcnt; long ttisstdcnt; long leapcnt; long timecnt; long typecnt; long charcnt; char buf[8]; struct tm tm; fp = fopen(filename, "r"); if (fp == NULL) wild2exit("result opening", filename); for (pass = 1; pass <= 2; ++pass) { if (fread(&tzh, sizeof tzh, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tversion\t", filename); c = tzh.tzh_version[0]; if (isascii(c) && isprint(c)) (void) putchar(c); else (void) printf("\\%o", c); (void) putchar('\n'); ttisgmtcnt = detzcode(tzh.tzh_ttisgmtcnt); ttisstdcnt = detzcode(tzh.tzh_ttisstdcnt); leapcnt = detzcode(tzh.tzh_leapcnt); timecnt = detzcode(tzh.tzh_timecnt); typecnt = detzcode(tzh.tzh_typecnt); charcnt = detzcode(tzh.tzh_charcnt); (void) printf("%s\tttisgmtcnt\t%ld\n", filename, ttisgmtcnt); (void) printf("%s\tttisstdcnt\t%ld\n", filename, ttisstdcnt); (void) printf("%s\tleapcnt\t%ld\n", filename, leapcnt); (void) printf("%s\ttimecnt\t%ld\n", filename, timecnt); (void) printf("%s\ttypecnt\t%ld\n", filename, typecnt); (void) printf("%s\tcharcnt\t%ld\n", filename, charcnt); for (i = 0; i < timecnt; ++i) { if (fread(buf, pass * 4, 1, fp) != 1) wild2exit("result reading", filename); ll = (pass == 1) ? detzcode(buf) : detzcode64(buf); { time_t l; l = ll; tm = *gmtime(&l); } (void) printf("%s\ttime[%d]\t%lld\t%s", filename, i, ll, asctime(&tm)); } for (i = 0; i < timecnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\ttype[%d]\t%d\n", filename, i, buf[0]); } for (i = 0; i < typecnt; ++i) { long l; if (fread(buf, 4, 1, fp) != 1) wild2exit("result reading", filename); l = detzcode(buf); (void) printf("%s\ttype[%d].offset\t%ld\n", filename, i, l); if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\ttype[%d].isdst\t%ld\n", filename, i, buf[0]); if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\ttype[%d].abbrind\t%ld\n", filename, i, buf[0]); } for (i = 0; i < charcnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tabbr[%d]\t", filename, i); if (isascii(buf[0]) && isprint(buf[0])) (void) printf("%c", buf[0]); else if (buf[0] == '\0') (void) printf("\\0"); else (void) printf("\%03o", buf[0]); (void) printf("\n"); } for (i = 0; i < ttisstdcnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tisstd[%d]\t%d\n", filename, i, buf[0]); } for (i = 0; i < ttisgmtcnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tisgmt[%d]\t%d\n", filename, i, buf[0]); } if (tzh.tzh_version[0] != '2') break; } if (fclose(fp) != 0) { (void) fprintf(stderr, "%s: wild result closing %s\n", progname, filename); exit(1); } } int main(argc, argv) int argc; char * argv[]; { int i; progname = argv[0]; for (i = 1; i < argc; ++i) handle(argv[i]); exit(0); } lecserver$ make tzhead cc -DTZDIR=\"/usr/local/etc/zoneinfo\" tzhead.c -o tzhead lecserver$ tzhead tmp/etc/zoneinfo/Europe/London | grep abbr tmp/etc/zoneinfo/Europe/London type[0].abbrind 0 tmp/etc/zoneinfo/Europe/London type[1].abbrind 4 tmp/etc/zoneinfo/Europe/London type[2].abbrind 8 tmp/etc/zoneinfo/Europe/London type[3].abbrind 0 tmp/etc/zoneinfo/Europe/London type[4].abbrind 0 tmp/etc/zoneinfo/Europe/London type[5].abbrind 4 tmp/etc/zoneinfo/Europe/London type[6].abbrind 4 tmp/etc/zoneinfo/Europe/London abbr[0] B tmp/etc/zoneinfo/Europe/London abbr[1] S tmp/etc/zoneinfo/Europe/London abbr[2] T tmp/etc/zoneinfo/Europe/London abbr[3] \0 tmp/etc/zoneinfo/Europe/London abbr[4] G tmp/etc/zoneinfo/Europe/London abbr[5] M tmp/etc/zoneinfo/Europe/London abbr[6] T tmp/etc/zoneinfo/Europe/London abbr[7] \0 tmp/etc/zoneinfo/Europe/London abbr[8] B tmp/etc/zoneinfo/Europe/London abbr[9] D tmp/etc/zoneinfo/Europe/London abbr[10] S tmp/etc/zoneinfo/Europe/London abbr[11] T tmp/etc/zoneinfo/Europe/London abbr[12] \0 tmp/etc/zoneinfo/Europe/London type[0].abbrind 0 tmp/etc/zoneinfo/Europe/London type[1].abbrind 4 tmp/etc/zoneinfo/Europe/London type[2].abbrind 8 tmp/etc/zoneinfo/Europe/London type[3].abbrind 12 tmp/etc/zoneinfo/Europe/London type[4].abbrind 4 tmp/etc/zoneinfo/Europe/London type[5].abbrind 4 tmp/etc/zoneinfo/Europe/London type[6].abbrind 8 tmp/etc/zoneinfo/Europe/London type[7].abbrind 8 tmp/etc/zoneinfo/Europe/London abbr[0] L tmp/etc/zoneinfo/Europe/London abbr[1] M tmp/etc/zoneinfo/Europe/London abbr[2] T tmp/etc/zoneinfo/Europe/London abbr[3] \0 tmp/etc/zoneinfo/Europe/London abbr[4] B tmp/etc/zoneinfo/Europe/London abbr[5] S tmp/etc/zoneinfo/Europe/London abbr[6] T tmp/etc/zoneinfo/Europe/London abbr[7] \0 tmp/etc/zoneinfo/Europe/London abbr[8] G tmp/etc/zoneinfo/Europe/London abbr[9] M tmp/etc/zoneinfo/Europe/London abbr[10] T tmp/etc/zoneinfo/Europe/London abbr[11] \0 tmp/etc/zoneinfo/Europe/London abbr[12] B tmp/etc/zoneinfo/Europe/London abbr[13] D tmp/etc/zoneinfo/Europe/London abbr[14] S tmp/etc/zoneinfo/Europe/London abbr[15] T tmp/etc/zoneinfo/Europe/London abbr[16] \0 lecserver$ exit script done on Fri 27 Jul 2007 11:25:04 AM EDT From: John B. Morrow [mailto:jmorrow at sendwordnow.com] Sent: Friday, July 27, 2007 2:29 AM To: tz at lecserver.nci.nih.gov Subject: Does zic currently compile time zone abbreviations correctly? In the process of extracting time zone information from the zoneinfo database, I noticed that the abbreviation pointer break for quite a few time zones including Europe/London, Asia/Dubai, and quite a few others.? The problem seems to be in the compiled time zone files so I spent some time looking at zic.? What seems to be happening is that zic uses some criteria to determine of the abbreviation (and other info for types) is used and won't write it if it thinks it isn't needed.? The problem is that it doesn't adjust the indexes (tt_abbrind) that reference those abbreviations, so they'll point to bad data or empty strings.? My quick (and admittedly heavy handed fix) was to force zic to write all of the abbreviations, whether they are necessary or not.? If this really is a problem, it should probably be fixed at some point.? Please note that the data in our fairly recently updated Linux server has abbreviations that don't seem to work. If I'm missing something or there is some other way more correct way to reference the abbreviations, please let me know.? I'm using tt_abbrind as per the tzfile man page and the tzcode2007f.tar.gz sources. John Morrow From markus.icu at gmail.com Fri Jul 27 18:38:00 2007 From: markus.icu at gmail.com (Markus Scherer) Date: Fri, 27 Jul 2007 11:38:00 -0700 Subject: FW: How to support such capabilites based on current Olson Time Zone implementation In-Reply-To: References: Message-ID: <6bb028490707271138x31eaae4es8d2cac06354bd4b6@mail.gmail.com> Dear Martin, For at least the first requirement, you might want to try other time zone support libraries listed on this list's homepage [1], for example ICU [2]. You could also send an email to the icu-support mailing list [3] to see if your second can be provided for. [1] http://www.twinsun.com/tz/tz-link.htm [2] http://icu-project.org/ [3] http://icu-project.org/contacts.html Best regards, markus From markus.icu at gmail.com Fri Jul 27 18:51:45 2007 From: markus.icu at gmail.com (Markus Scherer) Date: Fri, 27 Jul 2007 11:51:45 -0700 Subject: please update ICU homepage URL on http://www.twinsun.com/tz/tz-link.htm Message-ID: <6bb028490707271151g1f33a59k9a5d569d9e29fe26@mail.gmail.com> Dear TZ DB maintainers, Please update the ICU homepage URL on http://www.twinsun.com/tz/tz-link.htm from http://www-306.ibm.com/software/globalization/icu/ to http://icu-project.org/ Thanks and best regards, markus From yoshito_umaoka at us.ibm.com Fri Jul 27 19:00:49 2007 From: yoshito_umaoka at us.ibm.com (yoshito_umaoka at us.ibm.com) Date: Fri, 27 Jul 2007 15:00:49 -0400 Subject: FW: How to support such capabilites based on current Olson Time Zone implementation In-Reply-To: <6bb028490707271138x31eaae4es8d2cac06354bd4b6@mail.gmail.com> Message-ID: For the second requirement "getting the next nearest DST transition time", next version of ICU (ICU 3.8) will provide the API. -Yoshito "Markus Scherer" wrote on 07/27/2007 02:38:00 PM: > Dear Martin, > > For at least the first requirement, you might want to try other time > zone support libraries listed on this list's homepage [1], for example > ICU [2]. You could also send an email to the icu-support mailing list > [3] to see if your second can be provided for. > > [1] http://www.twinsun.com/tz/tz-link.htm > [2] http://icu-project.org/ > [3] http://icu-project.org/contacts.html > > Best regards, > markus From olsona at dc37a.nci.nih.gov Fri Jul 27 19:15:56 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Fri, 27 Jul 2007 15:15:56 -0400 Subject: FW: Does zic currently compile time zone abbreviations correctly? Message-ID: I'm forwarding this message from John Morrow, who is not on the time zone mailing list. Those of you who are on the time zone mailing list should direct replies appropriately. --ado -----Original Message----- From: John B. Morrow [mailto:jmorrow at sendwordnow.com] Sent: Friday, July 27, 2007 12:19 PM To: Olson, Arthur David (NIH/NCI) [E]; tz at lecserver.nci.nih.gov Subject: RE: Does zic currently compile time zone abbreviations correctly? This response and program was very helpful. Apparently I was missing the level of indirection that converted the type in the ttinfo into an abbrind to look up the abbreviation. For some time zones, that was fine and for others it wasn't. Now that I've added that additional level in, my program seems to be working correctly. Thank you for your quick response. John Morrow -----Original Message----- From: Olson, Arthur David (NIH/NCI) [E] [mailto:olsona at dc37a.nci.nih.gov] Sent: Friday, July 27, 2007 11:29 AM To: tz at elsie.nci.nih.gov Cc: John B. Morrow Subject: RE: Does zic currently compile time zone abbreviations correctly? The typescript below seems to indicate that there's nothing amiss with Europe/London; do you get different results if you run "tzhead"? --ado Script started on Fri 27 Jul 2007 11:24:37 AM EDT lecserver$ cat tzhead.c #include "private.h" struct tzhead { char tzh_magic[4]; /* TZ_MAGIC */ char tzh_version[1]; /* '\0' or '2' as of 2005 */ char tzh_reserved[15]; /* reserved--must be zero */ char tzh_ttisgmtcnt[4]; /* coded number of trans. time flags */ char tzh_ttisstdcnt[4]; /* coded number of trans. time flags */ char tzh_leapcnt[4]; /* coded number of leap seconds */ char tzh_timecnt[4]; /* coded number of transition times */ char tzh_typecnt[4]; /* coded number of local time types */ char tzh_charcnt[4]; /* coded number of abbr. chars */ }; static char * progname; static long long detzcode64(codep) const char * const codep; { register long long result; register int i; result = (codep[0] & 0x80) ? ~0L : 0L; for (i = 0; i < 8; ++i) result = result * 256 + (codep[i] & 0xff); return result; } static long long detzcode(codep) const char * const codep; { register long result; register int i; result = (codep[0] & 0x80) ? ~0L : 0L; for (i = 0; i < 4; ++i) result = (result << 8) | (codep[i] & 0xff); return result; } static void wild2exit(cp, dp) { (void) fprintf(stderr, "%s: wild result %s %s\n", progname, cp, dp); exit(1); } static void handle(filename) char * filename; { FILE * fp; struct tzhead tzh; long long ll; char c; int i; int pass; long ttisgmtcnt; long ttisstdcnt; long leapcnt; long timecnt; long typecnt; long charcnt; char buf[8]; struct tm tm; fp = fopen(filename, "r"); if (fp == NULL) wild2exit("result opening", filename); for (pass = 1; pass <= 2; ++pass) { if (fread(&tzh, sizeof tzh, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tversion\t", filename); c = tzh.tzh_version[0]; if (isascii(c) && isprint(c)) (void) putchar(c); else (void) printf("\\%o", c); (void) putchar('\n'); ttisgmtcnt = detzcode(tzh.tzh_ttisgmtcnt); ttisstdcnt = detzcode(tzh.tzh_ttisstdcnt); leapcnt = detzcode(tzh.tzh_leapcnt); timecnt = detzcode(tzh.tzh_timecnt); typecnt = detzcode(tzh.tzh_typecnt); charcnt = detzcode(tzh.tzh_charcnt); (void) printf("%s\tttisgmtcnt\t%ld\n", filename, ttisgmtcnt); (void) printf("%s\tttisstdcnt\t%ld\n", filename, ttisstdcnt); (void) printf("%s\tleapcnt\t%ld\n", filename, leapcnt); (void) printf("%s\ttimecnt\t%ld\n", filename, timecnt); (void) printf("%s\ttypecnt\t%ld\n", filename, typecnt); (void) printf("%s\tcharcnt\t%ld\n", filename, charcnt); for (i = 0; i < timecnt; ++i) { if (fread(buf, pass * 4, 1, fp) != 1) wild2exit("result reading", filename); ll = (pass == 1) ? detzcode(buf) : detzcode64(buf); { time_t l; l = ll; tm = *gmtime(&l); } (void) printf("%s\ttime[%d]\t%lld\t%s", filename, i, ll, asctime(&tm)); } for (i = 0; i < timecnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\ttype[%d]\t%d\n", filename, i, buf[0]); } for (i = 0; i < typecnt; ++i) { long l; if (fread(buf, 4, 1, fp) != 1) wild2exit("result reading", filename); l = detzcode(buf); (void) printf("%s\ttype[%d].offset\t%ld\n", filename, i, l); if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\ttype[%d].isdst\t%ld\n", filename, i, buf[0]); if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\ttype[%d].abbrind\t%ld\n", filename, i, buf[0]); } for (i = 0; i < charcnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tabbr[%d]\t", filename, i); if (isascii(buf[0]) && isprint(buf[0])) (void) printf("%c", buf[0]); else if (buf[0] == '\0') (void) printf("\\0"); else (void) printf("\%03o", buf[0]); (void) printf("\n"); } for (i = 0; i < ttisstdcnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tisstd[%d]\t%d\n", filename, i, buf[0]); } for (i = 0; i < ttisgmtcnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tisgmt[%d]\t%d\n", filename, i, buf[0]); } if (tzh.tzh_version[0] != '2') break; } if (fclose(fp) != 0) { (void) fprintf(stderr, "%s: wild result closing %s\n", progname, filename); exit(1); } } int main(argc, argv) int argc; char * argv[]; { int i; progname = argv[0]; for (i = 1; i < argc; ++i) handle(argv[i]); exit(0); } lecserver$ make tzhead cc -DTZDIR=\"/usr/local/etc/zoneinfo\" tzhead.c -o tzhead lecserver$ tzhead tmp/etc/zoneinfo/Europe/London | grep abbr tmp/etc/zoneinfo/Europe/London type[0].abbrind 0 tmp/etc/zoneinfo/Europe/London type[1].abbrind 4 tmp/etc/zoneinfo/Europe/London type[2].abbrind 8 tmp/etc/zoneinfo/Europe/London type[3].abbrind 0 tmp/etc/zoneinfo/Europe/London type[4].abbrind 0 tmp/etc/zoneinfo/Europe/London type[5].abbrind 4 tmp/etc/zoneinfo/Europe/London type[6].abbrind 4 tmp/etc/zoneinfo/Europe/London abbr[0] B tmp/etc/zoneinfo/Europe/London abbr[1] S tmp/etc/zoneinfo/Europe/London abbr[2] T tmp/etc/zoneinfo/Europe/London abbr[3] \0 tmp/etc/zoneinfo/Europe/London abbr[4] G tmp/etc/zoneinfo/Europe/London abbr[5] M tmp/etc/zoneinfo/Europe/London abbr[6] T tmp/etc/zoneinfo/Europe/London abbr[7] \0 tmp/etc/zoneinfo/Europe/London abbr[8] B tmp/etc/zoneinfo/Europe/London abbr[9] D tmp/etc/zoneinfo/Europe/London abbr[10] S tmp/etc/zoneinfo/Europe/London abbr[11] T tmp/etc/zoneinfo/Europe/London abbr[12] \0 tmp/etc/zoneinfo/Europe/London type[0].abbrind 0 tmp/etc/zoneinfo/Europe/London type[1].abbrind 4 tmp/etc/zoneinfo/Europe/London type[2].abbrind 8 tmp/etc/zoneinfo/Europe/London type[3].abbrind 12 tmp/etc/zoneinfo/Europe/London type[4].abbrind 4 tmp/etc/zoneinfo/Europe/London type[5].abbrind 4 tmp/etc/zoneinfo/Europe/London type[6].abbrind 8 tmp/etc/zoneinfo/Europe/London type[7].abbrind 8 tmp/etc/zoneinfo/Europe/London abbr[0] L tmp/etc/zoneinfo/Europe/London abbr[1] M tmp/etc/zoneinfo/Europe/London abbr[2] T tmp/etc/zoneinfo/Europe/London abbr[3] \0 tmp/etc/zoneinfo/Europe/London abbr[4] B tmp/etc/zoneinfo/Europe/London abbr[5] S tmp/etc/zoneinfo/Europe/London abbr[6] T tmp/etc/zoneinfo/Europe/London abbr[7] \0 tmp/etc/zoneinfo/Europe/London abbr[8] G tmp/etc/zoneinfo/Europe/London abbr[9] M tmp/etc/zoneinfo/Europe/London abbr[10] T tmp/etc/zoneinfo/Europe/London abbr[11] \0 tmp/etc/zoneinfo/Europe/London abbr[12] B tmp/etc/zoneinfo/Europe/London abbr[13] D tmp/etc/zoneinfo/Europe/London abbr[14] S tmp/etc/zoneinfo/Europe/London abbr[15] T tmp/etc/zoneinfo/Europe/London abbr[16] \0 lecserver$ exit script done on Fri 27 Jul 2007 11:25:04 AM EDT From: John B. Morrow [mailto:jmorrow at sendwordnow.com] Sent: Friday, July 27, 2007 2:29 AM To: tz at lecserver.nci.nih.gov Subject: Does zic currently compile time zone abbreviations correctly? In the process of extracting time zone information from the zoneinfo database, I noticed that the abbreviation pointer break for quite a few time zones including Europe/London, Asia/Dubai, and quite a few others.? The problem seems to be in the compiled time zone files so I spent some time looking at zic.? What seems to be happening is that zic uses some criteria to determine of the abbreviation (and other info for types) is used and won't write it if it thinks it isn't needed.? The problem is that it doesn't adjust the indexes (tt_abbrind) that reference those abbreviations, so they'll point to bad data or empty strings.? My quick (and admittedly heavy handed fix) was to force zic to write all of the abbreviations, whether they are necessary or not.? If this really is a problem, it should probably be fixed at some point.? Please note that the data in our fairly recently updated Linux server has abbreviations that don't seem to work. If I'm missing something or there is some other way more correct way to reference the abbreviations, please let me know.? I'm using tt_abbrind as per the tzfile man page and the tzcode2007f.tar.gz sources. John Morrow From cppcraze at gmail.com Mon Jul 30 09:21:51 2007 From: cppcraze at gmail.com (Martin Dong) Date: Mon, 30 Jul 2007 17:21:51 +0800 Subject: FW: How to support such capabilites based on current Olson Time Zone implementation In-Reply-To: References: <6bb028490707271138x31eaae4es8d2cac06354bd4b6@mail.gmail.com> Message-ID: Dear Markus and Yoshito, Thanks for leading me to ICU project, which is really a full-featured library for internationalization. I feel it's more appropriate to consider using it from the very initial system design. However our system has already had its own internationalization mechanism, now we only want to utilize Olson Time Zone database. We need a light-weight solution but I think ICU is too heavy for us. Actually tzcode is a light-weight implementation, if I can make some change based on it to support what I want, I think it's enough. Dear Olson, I want to know more about tzfile in binary form. Is there any other detailed description? I feel it's a little bit hard to get it understood just through the tzcode (because the comments are vrey few:-). Btw, for now can any new functionality be added into tzcode implementation? Or another question, if my change can meet my requirements and it goes into our system, does it need to go into Olson tzcode? Sincerely, -Martin On 7/28/07, yoshito_umaoka at us.ibm.com wrote: > > For the second requirement "getting the next nearest DST transition time", > next version of ICU (ICU 3.8) will provide the API. > > -Yoshito > > "Markus Scherer" wrote on 07/27/2007 02:38:00 PM: > > > Dear Martin, > > > > For at least the first requirement, you might want to try other time > > zone support libraries listed on this list's homepage [1], for example > > ICU [2]. You could also send an email to the icu-support mailing list > > [3] to see if your second can be provided for. > > > > [1] http://www.twinsun.com/tz/tz-link.htm > > [2] http://icu-project.org/ > > [3] http://icu-project.org/contacts.html > > > > Best regards, > > markus > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm.icann.org/pipermail/tz/attachments/20070730/065ad081/attachment-0001.html From olsona at dc37a.nci.nih.gov Mon Jul 30 13:29:03 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Mon, 30 Jul 2007 09:29:03 -0400 Subject: FW: How to support such capabilites based on current Olson Time Zone implementation Message-ID: I'm forwarding this message from Martin Doug, who is not on the time zone mailing list. Those of you who are on the time zone mailing list should direct replies appropriately. --ado From: Martin Dong [mailto:cppcraze at gmail.com] Sent: Monday, July 30, 2007 5:22 To: markus.icu at gmail.com; yoshito_umaoka at us.ibm.com Cc: tz at lecserver.nci.nih.gov Subject: Re: FW: How to support such capabilites based on current Olson Time Zone implementation Dear Markus and Yoshito, ? Thanks for leading me to ICU project, which is really a full-featured library for internationalization. I feel it's more appropriate to consider using it from the very?initial system design. However our system has already had its own internationalization mechanism, now we only want to utilize Olson Time Zone database.?We need a light-weight solution but I think ICU is too heavy for us. ? Actually tzcode is a light-weight implementation, if I can make some change based on it to support what I want, I think it's enough. ? Dear Olson, ? I want to know more about tzfile in binary form. Is there any other detailed description? I feel it's?a little bit hard to get it understood just through the tzcode (because the comments are vrey few:-). ? Btw,?for now can any new functionality be added into tzcode implementation? Or another question, if my change can meet my requirements and it goes into our system, does it need to go into Olson tzcode? ? Sincerely, -Martin ? On 7/28/07, yoshito_umaoka at us.ibm.com wrote: For the second requirement "getting the next nearest DST transition time", next version of ICU (ICU 3.8) will provide the API. -Yoshito "Markus Scherer" wrote on 07/27/2007 02:38:00 PM: > Dear Martin, > > For at least the first requirement, you might want to try other time > zone support libraries listed on this list's homepage [1], for example > ICU [2]. You could also send an email to the icu-support mailing list > [3] to see if your second can be provided for. > > [1] http://www.twinsun.com/tz/tz-link.htm > [2] http://icu-project.org/ > [3] http://icu-project.org/contacts.html > > Best regards, > markus From hellosticky at gmail.com Sun Jul 1 14:26:27 2007 From: hellosticky at gmail.com (Kevin) Date: Sun, 1 Jul 2007 10:26:27 -0400 Subject: FW: Implementation of zoneinfo (Olson, tz) database in .NET c-sharp csharp In-Reply-To: <87bqf9tdlu.fsf@penguin.cs.ucla.edu> References: <87bqf9tdlu.fsf@penguin.cs.ucla.edu> Message-ID: <6936856c0707010726k7c48f255t3f7c499de89222ca@mail.gmail.com> Hi tzlist, I created this PublicDomain package as well as the tz database integration. I had been meaning to notify the list, but the current support is quite experimental, so I was waiting until I could make it more robust to get public comments... Alas, I got caught up in creating a start-up (of which this PublicDomain set of classes is an off-shoot). I guess the cat's out of the bag :-) That's okay, and if anyone is interested in contributing, that would be greatly appreciated. A response to the questions is below.... On 6/21/07, Paul Eggert wrote: > "Olson, Arthur David (NIH/NCI) [E]" writes: > > > From: Joshua Kifer [mailto:joshua at jotts.com] > > Sent: Wednesday, June 20, 2007 8:33 PM > > > > http://www.codeplex.com/publicdomain > > Thanks for mentioning that. Do you know how it works? It appears to > have a copy of the tz database, translated into C# (how?). There is a class called TzDatabase which parses the tz database into logical constructs, then emits C# code, which is manually placed into the static initializer, and the whole package is recompiled. This adds a few seconds to each static initialization of the class, which is the trade off for not performing File I/O on DLL resources or the filesystem (mostly for security permission reasons). > > Suppose a new version of the tz database comes out: how would the > change be propagated? > A new version of PublicDomain would have to be created and this new DLL would be re-downloaded and installed (no automatic way of doing this). I am *very* open to criticisms. If there is a better way to implement tz database support, I would be interested; however, one of the main design goals was to require very little from the "integrator" (i.e. the consumer of PublicDomain and TzTimeZone/TzDateTime). Therefore, using resource files which must be loaded from the DLL or file system would require FileIOPermission, and I felt that a larger load time (due to static initialization) and the tz database compiled in was the better choice. I am open to changing this. By the way, if you install PublicDomain.msi, all code is placed into C:\Program Files\PublicDomain\ (it is not yet tested on Linux), including TzDatabase.cs, TzDateTime.cs, and TzTimeZone.cs. Thanks, Kevin Grigorenko From hellosticky at gmail.com Sun Jul 1 14:37:53 2007 From: hellosticky at gmail.com (Kevin) Date: Sun, 1 Jul 2007 10:37:53 -0400 Subject: FW: Implementation of zoneinfo (Olson, tz) database in .NET c-sharp csharp In-Reply-To: <6936856c0707010726k7c48f255t3f7c499de89222ca@mail.gmail.com> References: <87bqf9tdlu.fsf@penguin.cs.ucla.edu> <6936856c0707010726k7c48f255t3f7c499de89222ca@mail.gmail.com> Message-ID: <6936856c0707010737m50b4b270te6d4c37ec6a35017@mail.gmail.com> "Joshua Kifer" writes: >> the only thing being retained is the timezone name and its UTC >> offset. No historical data is utilized. > > Thanks. Here's a draft of what could go into tz-link.htm; comments > and corrections are welcome. > >
  • PublicDomain > has a copy of a recent tz database, accessed via a href="http://en.wikipedia.org/wiki/C_Sharp">C# library. As its > name suggests, it is in the public domain. Only current time stamps > are supported; historical data are not used.
    • By the way, the historical data exists, I just haven't implemented accessor methods to retrieve that data. This data is already compiled in to the runtime binary. However, it can be retrieved manually through the TzDatabase class, although that requires a local copy of the tz database. Thanks, Kevin From emuller at adobe.com Sun Jul 1 17:07:11 2007 From: emuller at adobe.com (Eric Muller) Date: Sun, 01 Jul 2007 10:07:11 -0700 Subject: Geographical boundaries for the continental US tz zones In-Reply-To: <465E634D.2080301@adobe.com> References: <465E634D.2080301@adobe.com> Message-ID: <4687DF3F.2080005@adobe.com> I have completed a first version of a map of the TZ timezones in the US. It is available as a shapefile at . Comments welcome, Eric. From CLawrence at stopwatchmaps.com Sun Jul 1 18:38:00 2007 From: CLawrence at stopwatchmaps.com (Christina Lawrence) Date: Sun, 1 Jul 2007 13:38:00 -0500 Subject: TimeZones and international waters In-Reply-To: <877ipxtcnp.fsf@penguin.cs.ucla.edu> Message-ID: Thank you for the response! What distance from shore defines "the territorial waters of any nation"? Is it nation specific, or an internationally recognized distance from shore? Thank you! Christina -----Original Message----- From: Paul Eggert [mailto:eggert at CS.UCLA.EDU] Sent: Thursday, June 21, 2007 12:56 PM To: tz at elsie.nci.nih.gov Cc: Christina Lawrence Subject: Re: TimeZones and international waters To help clear this up I'll add something like the following to my next proposed patch. Comments welcome. A ship within the territorial waters of any nation uses that nation's time. In international waters, time zone boundaries are meridians 15° apart, except that UTC−12 and UTC+12 are each 7.5° wide and are separated by the 180° meridian (not by the International Date Line, which is for land and territorial waters only). A captain can change ship's clocks any time after entering a new time zone; midnight changes are common. From pgoyette at juniper.net Sun Jul 1 18:50:08 2007 From: pgoyette at juniper.net (Paul Goyette) Date: Sun, 1 Jul 2007 11:50:08 -0700 Subject: TimeZones and international waters In-Reply-To: Message-ID: Generally, the territorial waters extend 12 miles from shore. In cases of conflict (ie, a point is less than 12 miles from the shores of two or more countries), the dividing line is established by treaty. I think there are still a few areas where treaties have not been adopted, so there might be some "gray" areas... International Treaties permit definition of "Economic Excclusion Zones" (the US EEZ is a 200-mile limit). Fishing limits apply in such areas, but boarding rights and controls over shipping etc. don not apply. Paul Goyette Juniper Networks Customer Service and former skipper of the 61' Cheoy Lee motor yacht "Gentle Wind" on her 2005 journey across the Pacific Ocean. > -----Original Message----- > From: Christina Lawrence [mailto:CLawrence at stopwatchmaps.com] > Sent: Sunday, July 01, 2007 11:38 AM > To: Paul Eggert > Cc: tz at lecserver.nci.nih.gov > Subject: RE: TimeZones and international waters > > Thank you for the response! > > What distance from shore defines "the territorial waters of > any nation"? > Is it nation specific, or an internationally recognized distance from > shore? > > Thank you! > > Christina > > > -----Original Message----- > From: Paul Eggert [mailto:eggert at CS.UCLA.EDU] > Sent: Thursday, June 21, 2007 12:56 PM > To: tz at elsie.nci.nih.gov > Cc: Christina Lawrence > Subject: Re: TimeZones and international waters > > To help clear this up I'll add something like the following to my next > proposed patch. Comments welcome. > > A ship within the territorial waters of any nation uses that nation's > time. In international waters, time zone boundaries are meridians > 15° apart, except that UTC−12 and UTC+12 are each 7.5° > wide and are separated by the 180° meridian (not by the > International Date Line, which is for land and territorial waters > only). A captain can change ship's clocks any time after entering a > new time zone; midnight changes are common. > From emuller at adobe.com Mon Jul 2 17:12:08 2007 From: emuller at adobe.com (Eric Muller) Date: Mon, 02 Jul 2007 10:12:08 -0700 Subject: French Polynesia Message-ID: <468931E8.7010206@adobe.com> If I read correctly the tz data for French Polynesia, there are three tz zones that are half an hour apart. I searched for an independent confirmation, but I can't find any evidence that FP has multiple local times. The best I have found so far is which suggests that all of FP is in a single timezone. Any idea of the source of the current data? Thanks, Eric. From wide.screen.software at mac.com Tue Jul 3 05:47:06 2007 From: wide.screen.software at mac.com (WIDE SCREEN SOFTWARE, LLC) Date: Mon, 2 Jul 2007 22:47:06 -0700 Subject: French Polynesia In-Reply-To: <468931E8.7010206@adobe.com> References: <468931E8.7010206@adobe.com> Message-ID: <379DAAE7-692F-4FF2-AD40-6301DBDEF615@mac.com> On Jul 2, 2007, at 10:12 AM, Eric Muller wrote: > If I read correctly the tz data for French Polynesia, there are > three tz zones that are half an hour apart. I searched for an > independent confirmation, but I can't find any evidence that FP has > multiple local times. The best I have found so far is > decouvrir_outre_mer/polynesie_francaise/ > publi_P_vie_pratique___decalage_horaire_1125327034760> > which suggests that all of FP is in a single timezone. > > Any idea of the source of the current data? > > Thanks, > Eric. > > > Eric, I am away working on location. I do not know if my wife had a chance to respond to your question. Check the following source that confirms the 3 time zones. http://home-4.tiscali.nl/~t876506/TZworld.html#pac If you have any questions please email. David Parrish (....on location) Wide Screen Software, LLC info at wide-screen.com http://www.wide-screen.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnorgard at prodigy.net.mx Mon Jul 9 01:08:01 2007 From: jnorgard at prodigy.net.mx (Jesper Norgaard Welen) Date: Sun, 08 Jul 2007 20:08:01 -0500 Subject: French Polynesia time zones Message-ID: Perhaps the following link will interest Eric Muller and the rest of the mailing list members: http://www.timegenie.com/country.time/pf/ The FAQ mentioned of the Tahiti tourism web site in fact has the URL http://www.tahiti-tourisme.com/planner/tahitifaqs.asp (it seems to have changed name since timegenie site documented it). Eric asked for a recognition of the three time zones in the tz database for French Polynesia. The explanation in the timegenie web site is: "According to the official Tahiti Tourisme web site, Tahiti and her Islands have two times zones. This information can be found in the FAQ section. However, Tahiti and her islands have in fact three time zones. The third time zone is not mentioned on the Tahiti Tourisme web site. Most likely, the third time zone is not mentioned since it is not visited by many tourists due to its distance from the main island of Tahiti. Since there is no official mention of the third time zone, timegenie.com contacted a Tahiti Tourisme office by phone. The result was that timegenie.com received official confirmation of the third time zone. Based on the information provided by Tahiti Tourisme, the majority of the islands, including the island of Tahiti itself, are -10 hours UTC/GMT. The Marquesas Islands are -9 hours 30 minutes UTC/GMT. The Gambier Islands are the third time zone and they are -9 hours UTC/GMT." I hope it's alright to quote timegenie for this information. I haven't found myself an official French Polynesia goverment web site confirming this information, but my french is limited to a 40-hour course so it is not to much use in this investigation. Regards, - Jesper Jesper N?rgaard Welen Email: jnorgard at Prodigy.Net.mx Project Leader (L?der de Proyecto) Software CIMMYT - Centro Internacional de Mejoramiento de Ma?z y Trigo Direcci?n: CIMMYT Int. c/o Jesper N?rgaard Km. 45, Carretera M?xico-Veracruz El Bat?n Texcoco, Edo. de M?xico CP 56130 MEXICO Tel.: +52 (55) 58-04-20-04 ext. 1374 Fax: +52 (55) 58-04-75-58 Tel. Casa: 53-10-05-95 ? 53-10-97-78 Download the shareware program World Time Explorer, I made: http://www.worldtimeexplorer.com/index.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkpublic at timklein.fastmail.fm Tue Jul 10 00:56:08 2007 From: tkpublic at timklein.fastmail.fm (Tim Klein) Date: Mon, 9 Jul 2007 19:56:08 -0500 Subject: Is there a list of "current" time zones? Message-ID: I'm new here. As I look through the tz database, and the archives of this mailing list, I realize what a phenomenal effort you folks have put in, to make all of this information available. Thank you for all you've done! A question... I'm helping to write an application that needs a menu for the user to choose what time zone they live in. With ~400 time zones in the database, that'd be a pretty daunting pull-down menu. But as I understand it, a significant fraction of the ~400 time zones exist only for historical reasons. Since our application will deal only with current and future times, historical distinctions don't matter, and we'd like the menu to show only the subset of time zones that are currently "in effect". (And we don't mind if it isn't painstakingly accurate or updated in real time.) Has anyone created such a list? Or maybe an algorithm (if not code) for generating one from the full database? I see that this question has come up in the past. To quote from the archives... ====== >From: "Andy Lipscomb" >Perhaps a better term would be "historical" time zones. This would >in fact be a useful distinction, since only a relatively small >subset of the timezones are necessary for applications that look >only forward--these would be the first set to present to a user for >selecting a time zone, with a "show all" option to get the complete >list. (For example, the 50 United States can be covered on a >forward-looking basis by eight zones--New York, Chicago, Denver, >Phoenix, Los Angeles, Anchorage, Adak, and Honolulu. And if one >takes as irrevocable the power of the EU over DST dates, then--for >example--London, Paris, and Helsinki would cover that entire area, >except for the different abbreviations used in the three +0 >countries.) ====== And... >From: Paul Eggert [mailto:eggert at CS.UCLA.EDU] >Sent: November 6, 2006 12:13 PM > >> Is there any way to flag some of the old historical zones such that >> they don't appear when running "tzselect"? > >We could have a table for people who don't care about historical >times, which maps zone names to "modern" zone names, and tzselect >could have an option to use that table. ====== Thank you very much for any wisdom on this subject! Tim Klein Dallas, Texas, USA From eulevik at gmail.com Tue Jul 10 01:56:21 2007 From: eulevik at gmail.com (Eric Ulevik) Date: Tue, 10 Jul 2007 11:56:21 +1000 Subject: Is there a list of "current" time zones? In-Reply-To: References: Message-ID: On 7/10/07, Tim Klein wrote: > I'm helping to write an application that needs a menu for the user to > choose what time zone they live in. With ~400 time zones in the > database, that'd be a pretty daunting pull-down menu. You will find this menu in quite a few places. Generally people don't have a problem identifying their geographical location - which is what this list shows. To simplify the menu, get the user to first choose a continent (eg. "Australia" or "Europe") then a region from a smaller list. You could also move the most common selections to the top of the list. Regards, Eric Ulevik From philip.howell at evalua.com.au Tue Jul 10 02:21:25 2007 From: philip.howell at evalua.com.au (Philip Howell) Date: Tue, 10 Jul 2007 12:21:25 +1000 Subject: Is there a list of "current" time zones? In-Reply-To: <"a06240819c2b88521e5ea(a)(091)192.168.1.104(093)*"@MHS> References: <"a06240819c2b88521e5ea(a)(091)192.168.1.104(093)*"@MHS> Message-ID: <4692ED25.4080904@evalua.com.au> Hi Tim, In the tzdata tarball is a file called zone.tab. It lists the current time zones grouped by country code. Cheers, Phil Tim Klein wrote: > I'm new here. As I look through the tz database, and the archives of > this mailing list, I realize what a phenomenal effort you folks have > put in, to make all of this information available. Thank you for all > you've done! > > A question... > > I'm helping to write an application that needs a menu for the user to > choose what time zone they live in. With ~400 time zones in the > database, that'd be a pretty daunting pull-down menu. > > But as I understand it, a significant fraction of the ~400 time zones > exist only for historical reasons. Since our application will deal > only with current and future times, historical distinctions don't > matter, and we'd like the menu to show only the subset of time zones > that are currently "in effect". (And we don't mind if it isn't > painstakingly accurate or updated in real time.) > > Has anyone created such a list? Or maybe an algorithm (if not code) > for generating one from the full database? > > I see that this question has come up in the past. To quote from the > archives... > > ====== > >> From: "Andy Lipscomb" >> Perhaps a better term would be "historical" time zones. This would in >> fact be a useful distinction, since only a relatively small subset of >> the timezones are necessary for applications that look only >> forward--these would be the first set to present to a user for >> selecting a time zone, with a "show all" option to get the complete >> list. (For example, the 50 United States can be covered on a >> forward-looking basis by eight zones--New York, Chicago, Denver, >> Phoenix, Los Angeles, Anchorage, Adak, and Honolulu. And if one takes >> as irrevocable the power of the EU over DST dates, then--for >> example--London, Paris, and Helsinki would cover that entire area, >> except for the different abbreviations used in the three +0 countries.) > > ====== > And... > >> From: Paul Eggert [mailto:eggert at CS.UCLA.EDU] >> Sent: November 6, 2006 12:13 PM >> >>> Is there any way to flag some of the old historical zones such that >>> they don't appear when running "tzselect"? >> >> We could have a table for people who don't care about historical >> times, which maps zone names to "modern" zone names, and tzselect >> could have an option to use that table. > > ====== > > Thank you very much for any wisdom on this subject! > > Tim Klein > Dallas, Texas, USA > > From olsona at dc37a.nci.nih.gov Tue Jul 10 13:29:20 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Tue, 10 Jul 2007 09:29:20 -0400 Subject: FW: Time Zone mapping --> Windows ??? Message-ID: I'm forwarding this message from Boris Lang, who is not on the time zone mailing list. Those of you who are on the time zone mailing list should direct replies appropriately. --ado -----Original Message----- From: BORIS LANG [mailto:BORIS.LANG at MEMO.IKEA.COM] Sent: Tuesday, July 10, 2007 8:55 AM To: tz at lecserver.nci.nih.gov Subject: Time Zone mapping --> Windows ??? --- Received from IKEA4.BRLG +49 6122 5858276 07-07-10 14.56 -------------------------------------- Hi, we are working on the implementation of time zone information into an application using the tz database. TZ data names will be our main type but we also need to do a mapping to the time zone names used in windows. i.e. Europe/Berlin (tzd) --> Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna (Windows) The problem is that I can?t find a complete list that contains the mapping from tz database to windows. Can somebody please help us? Is there already such a list existing? Best regards Boris Lang ------ IKEA IT Germany GmbH Am Wandersmann 2-4 65719 Hofheim-Wallau Sitz M?nchen HR B 79392, Amtsgericht M?nchen Gesch?ftsf?hrer: Manfred Godlewski, G?ran Sj?strand, Ola Troedsson ---- 07-07-10 14.56 ---- Sent to --------------------------------------------------------------------------------- -> tz at elsie.nci.nih.gov From GMANE at faerber.muc.de Tue Jul 10 09:42:23 2007 From: GMANE at faerber.muc.de (=?ISO-8859-1?Q?Claus_F=E4rber?=) Date: Tue, 10 Jul 2007 11:42:23 +0200 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: References: Message-ID: Andy Lipscomb schrieb: > As was largely hashed out over China, changing to Hanoi would in fact *not* be consistent--the standard is largest city, not necessarily capital. (For example, Australia, Canada, China, India, New Zealand, South Africa, and the USA do not have explicit listings for their capital cities.) I argued that Beijing should be in because of its significance in determining Chinese-calendar dates, but lost that one. As for what to call any given city, on that I have no opinion. As the term city is ambiguous, the standard is ambiguous and inconsistent anyway. If city is defined as municipality, the following are wrong: Europe/London should be Europe/Birmingham Asia/Tokyo should be Asia/Yokohama Australia/Sydney should be Australia/Blacktown ... and probably dozens others. The largest "cities" often consist of multiple municipalities, which makes this definition insensible. However, if city is defined as metropolitan area, the following are clearly wrong: Europe/Berlin should be Europe/Rhein-Rhur Europe/Rome should be Europe/Milan Asia/Calcutta should be Asia/Mumbai Asia/Karachi should be Asia/Lahor IMO, the standard should be changed from "largest city" to "most important city". Importance would be primarily derived from the population count but with respect to factors such as legal status (city, capital) and views of the local population. Claus From dot at dotat.at Tue Jul 10 14:59:31 2007 From: dot at dotat.at (Tony Finch) Date: Tue, 10 Jul 2007 15:59:31 +0100 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: References: Message-ID: On Tue, 10 Jul 2007, Claus F?rber wrote: > > If city is defined as municipality, the following are wrong: > > Europe/London should be Europe/Birmingham Not if it's London as in the Greater London Authority (or, historically, the Greater London Council, the London County Council, etc.), as opposed to the City of London which has been only a small part of the geography and government of the greater city for centuries. Tony. -- f.a.n.finch http://dotat.at/ IRISH SEA: NORTHWEST 4 OR 5, OCCASIONALLY 6. SLIGHT OR MODERATE. SHOWERS. MAINLY GOOD. From GMANE at faerber.muc.de Tue Jul 10 16:13:14 2007 From: GMANE at faerber.muc.de (=?UTF-8?B?Q2xhdXMgRsOkcmJlcg==?=) Date: Tue, 10 Jul 2007 18:13:14 +0200 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: References: Message-ID: Tony Finch schrieb: > On Tue, 10 Jul 2007, Claus F?rber wrote: >> If city is defined as municipality, the following are wrong: >> >> Europe/London should be Europe/Birmingham > > Not if it's London as in the Greater London Authority (or, historically, > the Greater London Council, the London County Council, etc.), as opposed > to the City of London which has been only a small part of the geography > and government of the greater city for centuries. The GLA is a super-city authority, covering multiple cities such as the City of London, the City of Westminster, etc. Well, that just proves my point that the term "city" introduces ambiguity. It's simply inconsistent to treat Greater London as a "city", which is made up of multiple municipalities like the City of London, Westminster, etc., but not the Ruhrgebiet (5.3 million and thus larger than Berlin, 3.4 million), which is made up of municipalities like Essen, Bochum or Dortmund and also has a super-city authority: the Regionalverband Ruhr (RVR). It's also inconsistent to treat Greater London as a "city" and not Greater Milan (7 million), which would be substantially larger than Rome or Greater Rome (2.5 or 3.3 million). Bending the rules in similar ways, Shanghai (??) suddenly has a population of 9.4 millions (the agglomeration, not the larger administrative area) and Beijing (??) has 11.5 millions (the agglomeration, not the administrative area and not the "core city"). It does not work with Saigon/Ho Chi Minh City (Th?nh ph? H? Ch? Minh) and Hanoi (H? N?i), though. Claus From vuntz at gnome.org Tue Jul 10 17:23:50 2007 From: vuntz at gnome.org (Vincent Untz) Date: Tue, 10 Jul 2007 19:23:50 +0200 Subject: Localization of timezones from zone.tab Message-ID: <20070710172350.GI30640@vuntz.net> Hi, [please keep me cc'ed since I'm not subscribed to this list] I know that, at least in GNOME, there are now three places where we parse zone.tab to get a list of timezones supported by the OS. I suppose other projects are also doing this. This list is then presented to the user to let him choose the timezone. The problem here is that we let the user choose strings which look like "Antarctica/South_Pole". This is not really good for non-english-speaking people ;-) Of course, we can add all the timezones to our list of strings to translate, but this means all projects needing to do so will duplicate this work and the translations. I'd like the tz database to ship translations in po files. This would imply the following: + create a small script to generate a POT file from zone.tab (easy) + submit the POT file to the translation project [1] (or any other place that helps with translation) + add the po files for translation to the tz database + choose a gettext domain (Of course, I'm quite probably forgetting about a step :-)) I've seen that this topic has been discussed before [2], but the proposition there was really more ambitious, so I'm hoping a simple approach would be welcomed. What do you think? Thanks, [1] http://translationproject.org/ [2] http://osdir.com/ml/time.tz/2004-09/msg00000.html Vincent -- Les gens heureux ne sont pas press?s. From olsona at dc37a.nci.nih.gov Tue Jul 10 17:26:23 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Tue, 10 Jul 2007 13:26:23 -0400 Subject: FW: Localization of timezones from zone.tab Message-ID: I'm forwarding this message from Vincent Untz, who is not on the time zone mailing list. Those of you who are on the time zone mailing list should direct replies appropriately. --ado -----Original Message----- From: Vincent Untz [mailto:vuntz at gnome.org] Sent: Tuesday, July 10, 2007 1:24 PM To: tz at lecserver.nci.nih.gov Subject: Localization of timezones from zone.tab Hi, [please keep me cc'ed since I'm not subscribed to this list] I know that, at least in GNOME, there are now three places where we parse zone.tab to get a list of timezones supported by the OS. I suppose other projects are also doing this. This list is then presented to the user to let him choose the timezone. The problem here is that we let the user choose strings which look like "Antarctica/South_Pole". This is not really good for non-english-speaking people ;-) Of course, we can add all the timezones to our list of strings to translate, but this means all projects needing to do so will duplicate this work and the translations. I'd like the tz database to ship translations in po files. This would imply the following: + create a small script to generate a POT file from zone.tab (easy) + submit the POT file to the translation project [1] (or any other place that helps with translation) + add the po files for translation to the tz database + choose a gettext domain (Of course, I'm quite probably forgetting about a step :-)) I've seen that this topic has been discussed before [2], but the proposition there was really more ambitious, so I'm hoping a simple approach would be welcomed. What do you think? Thanks, [1] http://translationproject.org/ [2] http://osdir.com/ml/time.tz/2004-09/msg00000.html Vincent -- Les gens heureux ne sont pas press?s. From AndyLipscomb at decosimo.com Tue Jul 10 17:34:11 2007 From: AndyLipscomb at decosimo.com (Andy Lipscomb) Date: Tue, 10 Jul 2007 13:34:11 -0400 Subject: Localization of timezones from zone.tab In-Reply-To: Message-ID: Currently, the main effort to localize time-zone information is in the Common Language Data Repository (I think that's what it's called, I know it's CLDR for initials), hosted at http://www.unicode.org/cldr; for each zone, there is the option to localize two names (DST and standard), the initials for those names, and the example city. J Andrew Lipscomb, CPA*ABV, ASA Decosimo Corporate Finance 900 Tallan Building 2 Union Square Chattanooga, TN 37402 423.756.7100 Fax 423.266.6671 www.dcf.decosimo.com -----Original Message----- From: Olson, Arthur David (NIH/NCI) [E] [mailto:olsona at dc37a.nci.nih.gov] Sent: Tue 10 July 2007 13:26 To: tz at lecserver.nci.nih.gov Cc: vuntz at gnome.org Subject: FW: Localization of timezones from zone.tab I'm forwarding this message from Vincent Untz, who is not on the time zone mailing list. Those of you who are on the time zone mailing list should direct replies appropriately. --ado -----Original Message----- From: Vincent Untz [mailto:vuntz at gnome.org] Sent: Tuesday, July 10, 2007 1:24 PM To: tz at lecserver.nci.nih.gov Subject: Localization of timezones from zone.tab Hi, [please keep me cc'ed since I'm not subscribed to this list] I know that, at least in GNOME, there are now three places where we parse zone.tab to get a list of timezones supported by the OS. I suppose other projects are also doing this. This list is then presented to the user to let him choose the timezone. The problem here is that we let the user choose strings which look like "Antarctica/South_Pole". This is not really good for non-english-speaking people ;-) Of course, we can add all the timezones to our list of strings to translate, but this means all projects needing to do so will duplicate this work and the translations. I'd like the tz database to ship translations in po files. This would imply the following: + create a small script to generate a POT file from zone.tab (easy) + submit the POT file to the translation project [1] (or any other place that helps with translation) + add the po files for translation to the tz database + choose a gettext domain (Of course, I'm quite probably forgetting about a step :-)) I've seen that this topic has been discussed before [2], but the proposition there was really more ambitious, so I'm hoping a simple approach would be welcomed. What do you think? Thanks, [1] http://translationproject.org/ [2] http://osdir.com/ml/time.tz/2004-09/msg00000.html Vincent -- Les gens heureux ne sont pas press?s. From mark.davis at icu-project.org Tue Jul 10 17:44:14 2007 From: mark.davis at icu-project.org (Mark Davis) Date: Tue, 10 Jul 2007 10:44:14 -0700 Subject: FW: Localization of timezones from zone.tab In-Reply-To: References: Message-ID: <30b660a20707101044n2c21c123l19f9b718d4bb5050@mail.gmail.com> The Unicode CLDR project (http://unicode.org/cldr/) does supply translations for timezone IDs. There are a few caveats. 1. The timezone database really has equivalence classes of IDs. One of these can be used as a representative for any in the equivalence class. It is the zone.tab file that contains such IDs. CLDR started by using that file, but unfortunately it is not stable (different equivalent IDs can be substituted at any time). So what we do is use as the representative the one that historically the first one used in any zone.tab file (after CLDR started). 2. We allow, but do not encourage, translation of zones that are the only zone in a country. For that we use the country name. This cuts down very substantially on the number of translations needed. That is, you would see the equivalent of "Italy", and "United States (Los Angeles)" -- only in the latter case do we need translations for the cities. 3. Translators can optionally add other variations: daylight (summer) time, standard (winter) time, and generic time, both abbreviated and long. 4. These choices percolate out to clients of CLDR: Google, IBM, Apple, Adobe, and many others. Mark On 7/10/07, Olson, Arthur David (NIH/NCI) [E] wrote: > > I'm forwarding this message from Vincent Untz, who is not on the time zone > mailing list. > > Those of you who are on the time zone mailing list should direct replies > appropriately. > > --ado > > -----Original Message----- > From: Vincent Untz [mailto:vuntz at gnome.org] > Sent: Tuesday, July 10, 2007 1:24 PM > To: tz at lecserver.nci.nih.gov > Subject: Localization of timezones from zone.tab > > Hi, > > [please keep me cc'ed since I'm not subscribed to this list] > > I know that, at least in GNOME, there are now three places where we > parse zone.tab to get a list of timezones supported by the OS. I suppose > other projects are also doing this. This list is then presented to the > user to let him choose the timezone. > > The problem here is that we let the user choose strings which look like > "Antarctica/South_Pole". This is not really good for > non-english-speaking people ;-) > > Of course, we can add all the timezones to our list of strings to > translate, but this means all projects needing to do so will duplicate > this work and the translations. > > I'd like the tz database to ship translations in po files. This would > imply the following: > > + create a small script to generate a POT file from zone.tab (easy) > + submit the POT file to the translation project [1] (or any other > place that helps with translation) > + add the po files for translation to the tz database > + choose a gettext domain > > (Of course, I'm quite probably forgetting about a step :-)) > > I've seen that this topic has been discussed before [2], but the > proposition there was really more ambitious, so I'm hoping a simple > approach would be welcomed. > > What do you think? > > Thanks, > > [1] http://translationproject.org/ > [2] http://osdir.com/ml/time.tz/2004-09/msg00000.html > > Vincent > > -- > Les gens heureux ne sont pas press?s. > -- Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From rlaw at nc.rr.com Tue Jul 10 18:38:02 2007 From: rlaw at nc.rr.com (rlaw at nc.rr.com) Date: Tue, 10 Jul 2007 14:38:02 -0400 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: References: Message-ID: > As the term city is ambiguous, the standard is ambiguous and > inconsistent anyway. How can we put an end to the incessant disputation over time zone identifiers? If we go by metropolitan area populations, someone will say we should go by central city populations. If we use any criterion that chooses Hanoi, someone will say Ho Chi Minh City is more important; but others will argue that the capital city is always more important. We must bear in mind that these are only supposed to be identifiers. Conceptually, we could be using WT/QAF just as well as Europe/Rome. It was merely for the convenience of developers that mnemonic names were chosen. But it is the responsibility of a user interface, not of the tz database, to translate the time zone identifiers into user-friendly names. The volunteer maintainers of the tz database have plenty of work to do, just to keep it up to date. If their job description is expanded to include making sure that the definitions of cities are consistent, providing universally acceptable names and abbreviations for time zones, or enabling localization by giving the translations of city, country, and time zone names into an arbitrary number of languages, I believe that puts too much on their plate. Presumably the CLDR addresses localization issues. Whoever maintains the CLDR has undertaken responsibility for interpreting the identifiers into human-readable form. Identifiers should be stable, too. True, by using backward-compatibility links, we can minimize the disruption caused by changing an identifier. Still, any kind of change has its cost, and a lot of the cost is hidden. We don't know how many people have used "Europe/Rome" somewhere in their code or nomenclature or documentation, and would deem it necessary to change the string if the primary name of that time zone changed to "Europe/Milan". (Of course, some changes are unavoidable, when time zones split.) My suggestion would be to state boldly in the documentation, "Time zone identifiers are arbitrary. Although they look as if they have a geographic interpretation, there is no guarantee that they do, or will continue to in the future. They should not be displayed directly to end users." Then, if possible, there should be some discussion of how to display time zone information to users. If we get GIS files for time zone boundaries, that will be a big help. Maintaining the boundary files would fall within the purview of the tz mailing list. Gwillim Law From chucks2 at veladg.com Tue Jul 10 20:37:17 2007 From: chucks2 at veladg.com (Chuck Soper) Date: Tue, 10 Jul 2007 13:37:17 -0700 Subject: FW: Localization of timezones from zone.tab Message-ID: I've been on the tz list for several years. I have tried to follow the Time Zone Localizations topic for CLDR. I do not understand why translations would be supplied for timezone IDs (tzIDs). Many tzIDs refer to the same time zone name. For example, I believe that Argentina has 2 time zone names, yet it has 10 tzIDs to handle DST rules for various states. Does this mean that 20 localized names would be required for Argentina? Does this mean that a new tzID would not be localized? Looking at 381 tzIDs of a tzData version (from 2006), I multiply it by two (for std and dst names) to obtain 762 time zone names required. By removing names of tzIDs that do not recognize DST and removing tzIDs that refer to the same time name (e.g. many tzIDs refer to Central European Time), I was to reduce total time zone names from 762 to 212. Can over 500 names can be removed from the translation list? Multiplying 500 potentially unneeded names by the number of translations would result in a large reduction of translation efforts. My approach is dependent on having a stable list of time zone names. As far as I know, such a list does not exist. If such a list existed, I would envision tzIDs being mapped to the 'time zone name' list. Chuck At 10:44 AM -0700 7/10/07, Mark Davis wrote: >The Unicode CLDR project >(http://unicode.org/cldr/) >does supply translations for timezone IDs. There >are a few caveats. > >1. The timezone database really has >equivalence classes of IDs. One of these can be >used as a representative for any in the >equivalence class. It is the zone.tab file that >contains such IDs. CLDR started by using that >file, but unfortunately it is not stable >(different equivalent IDs can be substituted at >any time). So what we do is use as the >representative the one that historically the >first one used in any zone.tab file (after CLDR >started). >2. We allow, but do not encourage, >translation of zones that are the only zone in a >country. For that we use the country name. This >cuts down very substantially on the number of >translations needed. That is, you would see the >equivalent of "Italy", and "United States (Los >Angeles)" -- only in the latter case do we need >translations for the cities. >3. Translators can optionally add other >variations: daylight (summer) time, standard >(winter) time, and generic time, both >abbreviated and long. >4. These choices percolate out to clients of >CLDR: Google, IBM, Apple, Adobe, and many others. > >Mark > >On 7/10/07, Olson, Arthur David (NIH/NCI) [E] ><olsona at dc37a.nci.nih.gov> >wrote: > >I'm forwarding this message from Vincent Untz, >who is not on the time zone mailing list. > >Those of you who are on the time zone mailing >list should direct replies appropriately. > > --ado > >-----Original Message----- >From: Vincent Untz [mailto: vuntz at gnome.org] >Sent: Tuesday, July 10, 2007 1:24 PM >To: tz at lecserver.nci.nih.gov >Subject: Localization of timezones from zone.tab > >Hi, > >[please keep me cc'ed since I'm not subscribed to this list] > >I know that, at least in GNOME, there are now three places where we >parse zone.tab to get a list of timezones supported by the OS. I suppose >other projects are also doing this. This list is then presented to the >user to let him choose the timezone. > >The problem here is that we let the user choose strings which look like >"Antarctica/South_Pole". This is not really good for >non-english-speaking people ;-) > >Of course, we can add all the timezones to our list of strings to >translate, but this means all projects needing to do so will duplicate >this work and the translations. > >I'd like the tz database to ship translations in po files. This would >imply the following: > >+ create a small script to generate a POT file from zone.tab (easy) >+ submit the POT file to the translation project [1] (or any other > place that helps with translation) >+ add the po files for translation to the tz database >+ choose a gettext domain > >(Of course, I'm quite probably forgetting about a step :-)) > >I've seen that this topic has been discussed before [2], but the >proposition there was really more ambitious, so I'm hoping a simple >approach would be welcomed. > >What do you think? > >Thanks, > >[1] http://translationproject.org/ >[2] > >http://osdir.com/ml/time.tz/2004-09/msg00000.html > >Vincent > >-- >Les gens heureux ne sont pas press?s. > > > > >-- >Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.davis at icu-project.org Tue Jul 10 20:54:19 2007 From: mark.davis at icu-project.org (Mark Davis) Date: Tue, 10 Jul 2007 13:54:19 -0700 Subject: FW: Localization of timezones from zone.tab In-Reply-To: References: Message-ID: <30b660a20707101354o58134e03l817d61b0778af44c@mail.gmail.com> We have actually instituted an alternative mechanism called 'metazones', which are somewhat like what you describe. They basically coalesce zones that have the same behavior in modern time. However, they have some further restrictions, and we only put this in recently thus haven't gathered enough data to be useful yet. Mark On 7/10/07, Chuck Soper wrote: > > I've been on the tz list for several years. I have tried to follow the > Time Zone Localizations topic for CLDR. > > I do not understand why translations would be supplied for timezone IDs > (tzIDs). Many tzIDs refer to the same time zone name. For example, I believe > that Argentina has 2 time zone names, yet it has 10 tzIDs to handle DST > rules for various states. Does this mean that 20 localized names would be > required for Argentina? Does this mean that a new tzID would not be > localized? > > Looking at 381 tzIDs of a tzData version (from 2006), I multiply it by two > (for std and dst names) to obtain 762 time zone names required. By removing > names of tzIDs that do not recognize DST and removing tzIDs that refer to > the same time name (e.g. many tzIDs refer to Central European Time), I was > to reduce total time zone names from 762 to 212. > > Can over 500 names can be removed from the translation list? Multiplying > 500 potentially unneeded names by the number of translations would result in > a large reduction of translation efforts. > > My approach is dependent on having a stable list of time zone names. As > far as I know, such a list does not exist. If such a list existed, I would > envision tzIDs being mapped to the 'time zone name' list. > > Chuck > > > At 10:44 AM -0700 7/10/07, Mark Davis wrote: > > The Unicode CLDR project (http://unicode.org/cldr/) does supply > translations for timezone IDs. There are a few caveats. > > 1. The timezone database really has equivalence classes of IDs. One > of these can be used as a representative for any in the equivalence class. > It is the zone.tab file that contains such IDs. CLDR started by using that > file, but unfortunately it is not stable (different equivalent IDs can be > substituted at any time). So what we do is use as the representative the one > that historically the first one used in any zone.tab file (after CLDR > started). > > 2. We allow, but do not encourage, translation of zones that are the > only zone in a country. For that we use the country name. This cuts down > very substantially on the number of translations needed. That is, you would > see the equivalent of "Italy", and "United States (Los Angeles)" -- only in > the latter case do we need translations for the cities. > > 3. Translators can optionally add other variations: daylight (summer) > time, standard (winter) time, and generic time, both abbreviated and long. > > 4. These choices percolate out to clients of CLDR: Google, IBM, > Apple, Adobe, and many others. > > Mark > > On 7/10/07,* Olson, Arthur David (NIH/NCI) [E]* > wrote: > > I'm forwarding this message from Vincent Untz, who is not on the time zone > mailing list. > > Those of you who are on the time zone mailing list should direct replies > appropriately. > > --ado > > -----Original Message----- > From: Vincent Untz [mailto: vuntz at gnome.org] > Sent: Tuesday, July 10, 2007 1:24 PM > To: tz at lecserver.nci.nih.gov > Subject: Localization of timezones from zone.tab > > Hi, > > [please keep me cc'ed since I'm not subscribed to this list] > > I know that, at least in GNOME, there are now three places where we > parse zone.tab to get a list of timezones supported by the OS. I suppose > other projects are also doing this. This list is then presented to the > user to let him choose the timezone. > > The problem here is that we let the user choose strings which look like > "Antarctica/South_Pole". This is not really good for > non-english-speaking people ;-) > > Of course, we can add all the timezones to our list of strings to > translate, but this means all projects needing to do so will duplicate > this work and the translations. > > I'd like the tz database to ship translations in po files. This would > imply the following: > > + create a small script to generate a POT file from zone.tab (easy) > + submit the POT file to the translation project [1] (or any other > > place that helps with translation) > > + add the po files for translation to the tz database > + choose a gettext domain > > (Of course, I'm quite probably forgetting about a step :-)) > > I've seen that this topic has been discussed before [2], but the > proposition there was really more ambitious, so I'm hoping a simple > approach would be welcomed. > > What do you think? > > Thanks, > > [1] http://translationproject.org/ > [2] http://osdir.com/ml/time.tz/2004-09/msg00000.html > > Vincent > > -- > Les gens heureux ne sont pas press?s. > > > > > -- > Mark > > > -- Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From chucks2 at veladg.com Tue Jul 10 21:49:10 2007 From: chucks2 at veladg.com (Chuck Soper) Date: Tue, 10 Jul 2007 14:49:10 -0700 Subject: FW: Localization of timezones from zone.tab In-Reply-To: <30b660a20707101354o58134e03l817d61b0778af44c@mail.gmail.com> References: <30b660a20707101354o58134e03l817d61b0778af44c@mail.gmail.com> Message-ID: Thanks for your response. I now remember meeting someone from IBM at an IMUG meeting at Apple; he described metazones. What is the best way for me to stay informed of CLDR related to time zones? And is there a way to make comments, suggestions or discuss? Chuck At 1:54 PM -0700 7/10/07, Mark Davis wrote: >We have actually instituted an alternative >mechanism called 'metazones', which are somewhat >like what you describe. They basically coalesce >zones that have the same behavior in modern >time. However, they have some further >restrictions, and we only put this in recently >thus haven't gathered enough data to be useful >yet. > >Mark > >On 7/10/07, Chuck Soper <chucks2 at veladg.com> wrote: > >I've been on the tz list for several years. I >have tried to follow the Time Zone Localizations >topic for CLDR. > >I do not understand why translations would be >supplied for timezone IDs (tzIDs). Many tzIDs >refer to the same time zone name. For example, I >believe that Argentina has 2 time zone names, >yet it has 10 tzIDs to handle DST rules for >various states. Does this mean that 20 localized >names would be required for Argentina? Does this >mean that a new tzID would not be localized? > >Looking at 381 tzIDs of a tzData version (from >2006), I multiply it by two (for std and dst >names) to obtain 762 time zone names required. >By removing names of tzIDs that do not recognize >DST and removing tzIDs that refer to the same >time name (e.g. many tzIDs refer to Central >European Time), I was to reduce total time zone >names from 762 to 212. > >Can over 500 names can be removed from the >translation list? Multiplying 500 potentially >unneeded names by the number of translations >would result in a large reduction of translation >efforts. > >My approach is dependent on having a stable list >of time zone names. As far as I know, such a >list does not exist. If such a list existed, I >would envision tzIDs being mapped to the 'time >zone name' list. > >Chuck > > >At 10:44 AM -0700 7/10/07, Mark Davis wrote: > >>The Unicode CLDR project >>(http://unicode.org/cldr/) >>does supply translations for timezone IDs. >>There are a few caveats. >> >>1. The timezone database really has >>equivalence classes of IDs. One of these can be >>used as a representative for any in the >>equivalence class. It is the zone.tab file that >>contains such IDs. CLDR started by using that >>file, but unfortunately it is not stable >>(different equivalent IDs can be substituted at >>any time). So what we do is use as the >>representative the one that historically the >>first one used in any zone.tab file (after CLDR >>started). >> >>2. We allow, but do not encourage, >>translation of zones that are the only zone in >>a country. For that we use the country name. >>This cuts down very substantially on the number >>of translations needed. That is, you would see >>the equivalent of "Italy", and "United States >>(Los Angeles)" -- only in the latter case do we >>need translations for the cities. >> >>3. Translators can optionally add other >>variations: daylight (summer) time, standard >>(winter) time, and generic time, both >>abbreviated and long. >> >>4. These choices percolate out to clients >>of CLDR: Google, IBM, Apple, Adobe, and many >>others. >> >Mark > >On 7/10/07, Olson, Arthur David (NIH/NCI) [E] ><olsona at dc37a.nci.nih.gov> >wrote: > >I'm forwarding this message from Vincent Untz, >who is not on the time zone mailing list. > >Those of you who are on the time zone mailing >list should direct replies appropriately. > > --ado > >-----Original Message----- >From: Vincent Untz [mailto: vuntz at gnome.org] >Sent: Tuesday, July 10, 2007 1:24 PM >To: tz at lecserver.nci.nih.gov >Subject: Localization of timezones from zone.tab > >Hi, > >[please keep me cc'ed since I'm not subscribed to this list] > >I know that, at least in GNOME, there are now three places where we >parse zone.tab to get a list of timezones supported by the OS. I suppose >other projects are also doing this. This list is then presented to the >user to let him choose the timezone. > >The problem here is that we let the user choose strings which look like >"Antarctica/South_Pole". This is not really good for >non-english-speaking people ;-) > >Of course, we can add all the timezones to our list of strings to >translate, but this means all projects needing to do so will duplicate >this work and the translations. > >I'd like the tz database to ship translations in po files. This would >imply the following: > >+ create a small script to generate a POT file from zone.tab (easy) >+ submit the POT file to the translation project [1] (or any other > > place that helps with translation) > >+ add the po files for translation to the tz database >+ choose a gettext domain > >(Of course, I'm quite probably forgetting about a step :-)) > >I've seen that this topic has been discussed before [2], but the >proposition there was really more ambitious, so I'm hoping a simple >approach would be welcomed. > >What do you think? > >Thanks, > >[1] http://translationproject.org/ >[2] > >http://osdir.com/ml/time.tz/2004-09/msg00000.html > >Vincent > >-- >Les gens heureux ne sont pas press?s. > > > > >-- >Mark > > > > > >-- >Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.davis at icu-project.org Tue Jul 10 22:05:53 2007 From: mark.davis at icu-project.org (Mark Davis) Date: Tue, 10 Jul 2007 15:05:53 -0700 Subject: FW: Localization of timezones from zone.tab In-Reply-To: References: <30b660a20707101354o58134e03l817d61b0778af44c@mail.gmail.com> Message-ID: <30b660a20707101505g3d545171o43fbf84ed35d6c59@mail.gmail.com> There is a users group at http://www.unicode.org/consortium/distlist.html#cldr_list. You can post suggestions/requests via the bug form on http://www.unicode.org/cldr/bugs/locale-bugs. If you belong to a Unicode member organization (http://www.unicode.org/consortium/memblogo.html) you can get on the internal list and even (if you choose) the weekly teleconference. Mark On 7/10/07, Chuck Soper wrote: > > Thanks for your response. I now remember meeting someone from IBM at an > IMUG meeting at Apple; he described metazones. > > What is the best way for me to stay informed of CLDR related to time > zones? And is there a way to make comments, suggestions or discuss? > > Chuck > > At 1:54 PM -0700 7/10/07, Mark Davis wrote: > > We have actually instituted an alternative mechanism called 'metazones', > which are somewhat like what you describe. They basically coalesce zones > that have the same behavior in modern time. However, they have some further > restrictions, and we only put this in recently thus haven't gathered enough > data to be useful yet. > > Mark > > On 7/10/07,* Chuck Soper* wrote: > > I've been on the tz list for several years. I have tried to follow the > Time Zone Localizations topic for CLDR. > > > I do not understand why translations would be supplied for timezone IDs > (tzIDs). Many tzIDs refer to the same time zone name. For example, I believe > that Argentina has 2 time zone names, yet it has 10 tzIDs to handle DST > rules for various states. Does this mean that 20 localized names would be > required for Argentina? Does this mean that a new tzID would not be > localized? > > > Looking at 381 tzIDs of a tzData version (from 2006), I multiply it by two > (for std and dst names) to obtain 762 time zone names required. By removing > names of tzIDs that do not recognize DST and removing tzIDs that refer to > the same time name (e.g. many tzIDs refer to Central European Time), I was > to reduce total time zone names from 762 to 212. > > > Can over 500 names can be removed from the translation list? Multiplying > 500 potentially unneeded names by the number of translations would result in > a large reduction of translation efforts. > > > My approach is dependent on having a stable list of time zone names. As > far as I know, such a list does not exist. If such a list existed, I would > envision tzIDs being mapped to the 'time zone name' list. > > > Chuck > > > > At 10:44 AM -0700 7/10/07, Mark Davis wrote: > > The Unicode CLDR project (http://unicode.org/cldr/) does supply > translations for timezone IDs. There are a few caveats. > > 1. The timezone database really has equivalence classes of IDs. One > of these can be used as a representative for any in the equivalence class. > It is the zone.tab file that contains such IDs. CLDR started by using that > file, but unfortunately it is not stable (different equivalent IDs can be > substituted at any time). So what we do is use as the representative the one > that historically the first one used in any zone.tab file (after CLDR > started). > > 2. We allow, but do not encourage, translation of zones that are the > only zone in a country. For that we use the country name. This cuts down > very substantially on the number of translations needed. That is, you would > see the equivalent of "Italy", and "United States (Los Angeles)" -- only in > the latter case do we need translations for the cities. > > 3. Translators can optionally add other variations: daylight (summer) > time, standard (winter) time, and generic time, both abbreviated and long. > > 4. These choices percolate out to clients of CLDR: Google, IBM, > Apple, Adobe, and many others. > > Mark > > On 7/10/07,* Olson, Arthur David (NIH/NCI) [E]* > wrote: > > I'm forwarding this message from Vincent Untz, who is not on the time zone > mailing list. > > Those of you who are on the time zone mailing list should direct replies > appropriately. > > --ado > > -----Original Message----- > From: Vincent Untz [mailto: vuntz at gnome.org] > Sent: Tuesday, July 10, 2007 1:24 PM > To: tz at lecserver.nci.nih.gov > Subject: Localization of timezones from zone.tab > > Hi, > > [please keep me cc'ed since I'm not subscribed to this list] > > I know that, at least in GNOME, there are now three places where we > > parse zone.tab to get a list of timezones supported by the OS. I suppose > other projects are also doing this. This list is then presented to the > user to let him choose the timezone. > > The problem here is that we let the user choose strings which look like > "Antarctica/South_Pole". This is not really good for > non-english-speaking people ;-) > > Of course, we can add all the timezones to our list of strings to > translate, but this means all projects needing to do so will duplicate > this work and the translations. > > I'd like the tz database to ship translations in po files. This would > imply the following: > > + create a small script to generate a POT file from zone.tab (easy) > + submit the POT file to the translation project [1] (or any other > > place that helps with translation) > > + add the po files for translation to the tz database > + choose a gettext domain > > (Of course, I'm quite probably forgetting about a step :-)) > > I've seen that this topic has been discussed before [2], but the > proposition there was really more ambitious, so I'm hoping a simple > approach would be welcomed. > > What do you think? > > Thanks, > > [1] http://translationproject.org/ > [2] http://osdir.com/ml/time.tz/2004-09/msg00000.html > > Vincent > > -- > Les gens heureux ne sont pas press?s. > > > > > -- > Mark > > > > > > -- > Mark > > > -- Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From Paul.Schauble at ticketmaster.com Tue Jul 10 22:12:44 2007 From: Paul.Schauble at ticketmaster.com (Paul Schauble) Date: Tue, 10 Jul 2007 15:12:44 -0700 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: References: Message-ID: <0165EECEBB4CF745ACF095E1176B03EA12C7FFE3@SUNCA-EXB-AV1.ticketmaster.corp> I suggested some time ago that zones should be named according to the authority that declared the zone. This would often result in country names or country name (subdivision). But it would also clearly identify things like "Navajo Time" as such rather than lumping this in with "Denver". I think this gives a more stable system that largest city. It completely avoids the issues of what is a city. And it avoids changing zone names when city population changes. ++PLS -----Original Message----- From: rlaw at nc.rr.com [mailto:rlaw at nc.rr.com] Sent: Tuesday, July 10, 2007 11:38 AM To: tz at lecserver.nci.nih.gov Subject: Re: Vietnam: Saigon is deprecated, should use capital Hanoi > As the term city is ambiguous, the standard is ambiguous and > inconsistent anyway. How can we put an end to the incessant disputation over time zone identifiers? If we go by metropolitan area populations, someone will say we should go by central city populations. If we use any criterion that chooses Hanoi, someone will say Ho Chi Minh City is more important; but others will argue that the capital city is always more important. We must bear in mind that these are only supposed to be identifiers. Conceptually, we could be using WT/QAF just as well as Europe/Rome. It was merely for the convenience of developers that mnemonic names were chosen. But it is the responsibility of a user interface, not of the tz database, to translate the time zone identifiers into user-friendly names. The volunteer maintainers of the tz database have plenty of work to do, just to keep it up to date. If their job description is expanded to include making sure that the definitions of cities are consistent, providing universally acceptable names and abbreviations for time zones, or enabling localization by giving the translations of city, country, and time zone names into an arbitrary number of languages, I believe that puts too much on their plate. Presumably the CLDR addresses localization issues. Whoever maintains the CLDR has undertaken responsibility for interpreting the identifiers into human-readable form. Identifiers should be stable, too. True, by using backward-compatibility links, we can minimize the disruption caused by changing an identifier. Still, any kind of change has its cost, and a lot of the cost is hidden. We don't know how many people have used "Europe/Rome" somewhere in their code or nomenclature or documentation, and would deem it necessary to change the string if the primary name of that time zone changed to "Europe/Milan". (Of course, some changes are unavoidable, when time zones split.) My suggestion would be to state boldly in the documentation, "Time zone identifiers are arbitrary. Although they look as if they have a geographic interpretation, there is no guarantee that they do, or will continue to in the future. They should not be displayed directly to end users." Then, if possible, there should be some discussion of how to display time zone information to users. If we get GIS files for time zone boundaries, that will be a big help. Maintaining the boundary files would fall within the purview of the tz mailing list. Gwillim Law From mark.davis at icu-project.org Tue Jul 10 23:45:53 2007 From: mark.davis at icu-project.org (Mark Davis) Date: Tue, 10 Jul 2007 16:45:53 -0700 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: <0165EECEBB4CF745ACF095E1176B03EA12C7FFE3@SUNCA-EXB-AV1.ticketmaster.corp> References: <0165EECEBB4CF745ACF095E1176B03EA12C7FFE3@SUNCA-EXB-AV1.ticketmaster.corp> Message-ID: <30b660a20707101645g4334f272k2444a65ecb0c10d3@mail.gmail.com> I agree with Gwillim Law; these are just identifiers. As far as I'm concerned, the best strategy would be 1. Never change remove or change what is in zone.tab. 2. Only add a new identifier to zone.tab if a zone splits. 3. For such a new identifier, pick the largest city in the new zone according to some reasonable authority (eg National Geographic Atlas of the World). Since it is just an identifier, don't worry about whether or not it includes metropolitan areas or how; don't worry about whether the authority is the best possible one or not. 4. Make sure that last field is unique, eg don't have America/United_States/San_Jose if you have America/Costa_Rica/San_Jose. If it would not be unique, choose a different identifier for zone.tab, or have some minor modification (San_Jose2) 5. Add aliases (links) where useful for clarification. Short of that, the current policies are reasonable, although it forces other parties (like CLDR) to impose additional measures for stability of identifiers. Mark On 7/10/07, Paul Schauble wrote: > > I suggested some time ago that zones should be named according to the > authority that declared the zone. This would often result in country > names or country name (subdivision). But it would also clearly identify > things like "Navajo Time" as such rather than lumping this in with > "Denver". > > I think this gives a more stable system that largest city. It completely > avoids the issues of what is a city. And it avoids changing zone names > when city population changes. > > ++PLS > > -----Original Message----- > From: rlaw at nc.rr.com [mailto:rlaw at nc.rr.com] > Sent: Tuesday, July 10, 2007 11:38 AM > To: tz at lecserver.nci.nih.gov > Subject: Re: Vietnam: Saigon is deprecated, should use capital Hanoi > > > As the term city is ambiguous, the standard is ambiguous and > > inconsistent anyway. > > How can we put an end to the incessant disputation over time zone > identifiers? If we go by metropolitan area populations, someone will > say we should go by central city populations. If we use any criterion > that chooses Hanoi, someone will say Ho Chi Minh City is more important; > but others will argue that the capital city is always more important. > > We must bear in mind that these are only supposed to be identifiers. > Conceptually, we could be using WT/QAF just as well as Europe/Rome. It > was merely for the convenience of developers that mnemonic names were > chosen. But it is the responsibility of a user interface, not of the tz > database, to translate the time zone identifiers into user-friendly > names. > > The volunteer maintainers of the tz database have plenty of work to do, > just to keep it up to date. If their job description is expanded to > include making sure that the definitions of cities are consistent, > providing universally acceptable names and abbreviations for time zones, > or enabling localization by giving the translations of city, country, > and time zone names into an arbitrary number of languages, I believe > that puts too much on their plate. > > Presumably the CLDR addresses localization issues. Whoever maintains > the CLDR has undertaken responsibility for interpreting the identifiers > into human-readable form. > > Identifiers should be stable, too. True, by using > backward-compatibility links, we can minimize the disruption caused by > changing an identifier. Still, any kind of change has its cost, and a > lot of the cost is hidden. We don't know how many people have used > "Europe/Rome" somewhere in their code or nomenclature or documentation, > and would deem it necessary to change the string if the primary name of > that time zone changed to "Europe/Milan". (Of course, some changes are > unavoidable, when time zones split.) > > My suggestion would be to state boldly in the documentation, "Time zone > identifiers are arbitrary. Although they look as if they have a > geographic interpretation, there is no guarantee that they do, or will > continue to in the future. They should not be displayed directly to end > users." Then, if possible, there should be some discussion of how to > display time zone information to users. If we get GIS files for time > zone boundaries, that will be a big help. Maintaining the boundary > files would fall within the purview of the tz mailing list. > > Gwillim Law > -- Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernard.desruisseaux at oracle.com Wed Jul 11 01:40:16 2007 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Tue, 10 Jul 2007 21:40:16 -0400 Subject: FW: Time Zone mapping --> Windows ??? In-Reply-To: References: Message-ID: <46943500.6020407@oracle.com> Mapping from Windows Time Zone Names to Olson Time Zone Keys http://www.chronos-st.org/Windows-to-Olson.html Unicode CLDR Version 1.5-draft: Windows --> Tzid http://unicode.org/cldr/data/diff/supplemental/windows_tzid.html Olson, Arthur David (NIH/NCI) [E] wrote: > I'm forwarding this message from Boris Lang, who is not on the time zone mailing list. > > Those of you who are on the time zone mailing list should direct replies appropriately. > > --ado > > -----Original Message----- > From: BORIS LANG [mailto:BORIS.LANG at MEMO.IKEA.COM] > Sent: Tuesday, July 10, 2007 8:55 AM > To: tz at lecserver.nci.nih.gov > Subject: Time Zone mapping --> Windows ??? > > --- Received from IKEA4.BRLG +49 6122 5858276 07-07-10 14.56 -------------------------------------- > > Hi, > > we are working on the implementation of time zone information into an application using the tz database. TZ data names > will be our main type but we also need to do a mapping to the time zone names used in windows. > > i.e. Europe/Berlin (tzd) --> Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna (Windows) > > > The problem is that I can?t find a complete list that contains the mapping from tz database to windows. > > Can somebody please help us? Is there already such a list existing? > > Best regards > Boris Lang > > > ------ > IKEA IT Germany GmbH > Am Wandersmann 2-4 > 65719 Hofheim-Wallau > > Sitz M?nchen HR B 79392, Amtsgericht M?nchen > Gesch?ftsf?hrer: Manfred Godlewski, G?ran Sj?strand, Ola Troedsson > > ---- 07-07-10 14.56 ---- Sent to --------------------------------------------------------------------------------- > -> tz at elsie.nci.nih.gov From autarch at urth.org Wed Jul 11 04:21:06 2007 From: autarch at urth.org (Dave Rolsky) Date: Tue, 10 Jul 2007 23:21:06 -0500 (CDT) Subject: FW: Time Zone mapping --> Windows ??? In-Reply-To: <46943500.6020407@oracle.com> References: <46943500.6020407@oracle.com> Message-ID: On Tue, 10 Jul 2007, Bernard Desruisseaux wrote: > Mapping from Windows Time Zone Names to Olson Time Zone Keys > http://www.chronos-st.org/Windows-to-Olson.html Unfortunately, these names are localized in Windows, so this mapping only works for English language Windows versions. I'm using this mapping in a Perl module I wrote (DateTime::TimeZone - http://search.cpan.org/dist/DateTime-TimeZone/) and got a bug report from a user regarding this issue. -dave /*=================================================== VegGuide.Org www.BookIRead.com Your guide to all that's veg. My book blog ===================================================*/ From kre at munnari.OZ.AU Wed Jul 11 13:15:33 2007 From: kre at munnari.OZ.AU (Robert Elz) Date: Wed, 11 Jul 2007 20:15:33 +0700 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: <0165EECEBB4CF745ACF095E1176B03EA12C7FFE3@SUNCA-EXB-AV1.ticketmaster.corp> References: <0165EECEBB4CF745ACF095E1176B03EA12C7FFE3@SUNCA-EXB-AV1.ticketmaster.corp> Message-ID: <19132.1184159733@munnari.OZ.AU> Date: Tue, 10 Jul 2007 15:12:44 -0700 From: "Paul Schauble" Message-ID: <0165EECEBB4CF745ACF095E1176B03EA12C7FFE3 at SUNCA-EXB-AV1.ticketmaster.corp> | I suggested some time ago that zones should be named according to the | authority that declared the zone. Does that work in the US, where all zones are under the authority of the Dept of Transport (or something like that) - you'd still need additional names to determine just which of the multiple different zones they meant - and even then dealing with historical names would mean that you can't just use the names the relevant dept assign, as they don't usually bother to provide names for things which are no longer current, but we need them. Just stop arguing about this silly issue - it doesn't really matter what the zones are called. City names are a fairly good choice, as it is very unlikely that a single city doesn't have a single timezone history and rules. Further, the biggest city is a good choice, as it is unlikely that people aren't going to know if the local time is different than whatever is the biggest regional city. Definitions of cities don't need to be precise - nothing really important depends upon the results - we aren't specifying the time that applies in that city, just using its name as the label for a time zone (where any unique label would do just as well - which is why when the city that would normally be selected doesn't have a unique enough name, we just pick another.) A "city" is just what some outsider would consider to be that city, so as far as I'm concerned, if I arrive at Heathrowe (or Gatwick) I'm in London. On the other hand, if I'm in Essen, I'm in Essen, the city, Ruhrgebiet, or Rhein-Ruhr is a region name, not a city, so they're not really options for us to choose. Stability is not too much of an issue either, nothing depends upon "biggest" that's just a convenient way to (try to) pick cities without having these endless absurd arguments. That's why "most important" is never going to work - all that would ever do is cause arguments, never settle any. Once picked, we retain the same city name, even if something else becomes bigger - at least until it is clear that some other city is substantially larger and going to remain that way. Whether we should be using Rome or Milan in Italy, I'll leave to someone who understands Italian geography and politics - if it should be Milan, we can just fix it (and of course, keep Rome as an alias). That is, if everyone who knows enough to have an opinion on this (which certainly excludes me) agrees that Milan is substantially bigger than Rome, and that isn't likely to change. If the issue is debatable enough for anyone to argue (reasonably) about, then we should just stick with what we have. The same for Calcutta/Mumbai and Karachi/Lahor. We already had the Beijing/Shanghai discussion, and while it may alter in the future, things don't yet seem clear cut enough to make a change there. kre From Masayoshi.Okutsu at Sun.COM Wed Jul 11 15:03:38 2007 From: Masayoshi.Okutsu at Sun.COM (Masayoshi Okutsu) Date: Thu, 12 Jul 2007 00:03:38 +0900 Subject: FW: Time Zone mapping --> Windows ??? In-Reply-To: References: <46943500.6020407@oracle.com> Message-ID: <4694F14A.4020907@sun.com> On 7/11/2007 1:21 PM, Dave Rolsky wrote: > On Tue, 10 Jul 2007, Bernard Desruisseaux wrote: > >> Mapping from Windows Time Zone Names to Olson Time Zone Keys >> http://www.chronos-st.org/Windows-to-Olson.html > > Unfortunately, these names are localized in Windows, so this mapping > only works for English language Windows versions. I'm using this > mapping in a Perl module I wrote (DateTime::TimeZone - > http://search.cpan.org/dist/DateTime-TimeZone/) and got a bug report > from a user regarding this issue. In case you are tring to find out the tzid for the current Windows time zone... The time zone names from GetTimeZoneInformation() are localized. You'd need to find the "Time Zones" registry entry that matches the GetTimeZoneInformation() return value. Then, its registry key name can be used to look up a mapping table. However, different Windows versions use different key names. And some old localized Windows (NT/2000) have localized key names. In that case Java uses the mapID value which is not in Windows XP with a time zone patch and Vista. IIRC, key name "GMT" is used for different time zones in different Windows versions. It's a mess if you try to map Windows time zones to tzids... Masayoshi From tkpublic at timklein.fastmail.fm Wed Jul 11 23:15:36 2007 From: tkpublic at timklein.fastmail.fm (Tim Klein) Date: Wed, 11 Jul 2007 18:15:36 -0500 Subject: Is there a list of "current" time zones? In-Reply-To: References: Message-ID: Thank you, to those who helped me with this question! Especially big thanks to the ICU project folks (icu-project.org), whose "metazones" work got us most of the way to the data we needed. Tim From vuntz at gnome.org Thu Jul 12 14:09:19 2007 From: vuntz at gnome.org (Vincent Untz) Date: Thu, 12 Jul 2007 16:09:19 +0200 Subject: Localization of timezones from zone.tab In-Reply-To: References: Message-ID: <20070712140919.GP30640@vuntz.net> Le mardi 10 juillet 2007, ? 13:34 -0400, Andy Lipscomb a ?crit : > Currently, the main effort to localize time-zone information is in the Common Language Data Repository (I think that's what it's called, I know it's CLDR for initials), hosted at http://www.unicode.org/cldr; for each zone, there is the option to localize two names (DST and standard), the initials for those names, and the example city. Thanks for the pointer. I didn't know that CLDR contains this. That's cool :-) Vincent -- Les gens heureux ne sont pas press?s. From clive at demon.net Fri Jul 13 09:05:52 2007 From: clive at demon.net (Clive D.W. Feather) Date: Fri, 13 Jul 2007 10:05:52 +0100 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: <30b660a20707101645g4334f272k2444a65ecb0c10d3@mail.gmail.com> References: <0165EECEBB4CF745ACF095E1176B03EA12C7FFE3@SUNCA-EXB-AV1.ticketmaster.corp> <30b660a20707101645g4334f272k2444a65ecb0c10d3@mail.gmail.com> Message-ID: <20070713090552.GF21582@finch-staff-1.thus.net> Mark Davis said: > I agree with Gwillim Law; these are just identifiers. As far as I'm > concerned, the best strategy would be > > 1. Never change remove or change what is in zone.tab. > 2. Only add a new identifier to zone.tab if a zone splits. I would certainly agree with those. Stability is more important than always providing the name of the current largest city. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | From clive at demon.net Fri Jul 13 09:17:50 2007 From: clive at demon.net (Clive D.W. Feather) Date: Fri, 13 Jul 2007 10:17:50 +0100 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: References: Message-ID: <20070713091750.GG21582@finch-staff-1.thus.net> Claus F?rber said: >> Not if it's London as in the Greater London Authority (or, historically, >> the Greater London Council, the London County Council, etc.), as opposed >> to the City of London which has been only a small part of the geography >> and government of the greater city for centuries. > The GLA is a super-city authority, covering multiple cities such as the > City of London, the City of Westminster, etc. Well, that just proves my > point that the term "city" introduces ambiguity. The term "city" has at least three meanings within the UK: (1) [the legal definition] A local authority area granted city status by the crown. The LA may be a District, a Borough, or a Parish. (2) [the pub lawyer's definition] A conurbation containing a cathedral. (3) [colloquial] A large conurbation. London is a city under the second and third definitions, and a local authority area containing two cities under the first. But so what? Every country has its own concept of what a "city" is and how it differs from a town. The colloquial one is probably better *FOR THIS PURPOSE* than either of the other two. > It's simply inconsistent to treat Greater London as a "city", which is > made up of multiple municipalities like the City of London, Westminster, > etc., They aren't municipalities, they're boroughs. And Birmingham is equally split up into wards. So what? > It's also inconsistent to treat Greater London as a "city" and not > Greater Milan (7 million), which would be substantially larger than > Rome or Greater Rome (2.5 or 3.3 million). Does "Greater Milan" have a single governmental authority? -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | From kre at munnari.OZ.AU Fri Jul 13 13:59:11 2007 From: kre at munnari.OZ.AU (Robert Elz) Date: Fri, 13 Jul 2007 20:59:11 +0700 Subject: Vietnam: Saigon is deprecated, should use capital Hanoi In-Reply-To: <20070713091750.GG21582@finch-staff-1.thus.net> References: <20070713091750.GG21582@finch-staff-1.thus.net> Message-ID: <16339.1184335151@munnari.OZ.AU> Date: Fri, 13 Jul 2007 10:17:50 +0100 From: "Clive D.W. Feather" Message-ID: <20070713091750.GG21582 at finch-staff-1.thus.net> | But so what? Every country has its own concept of what a "city" is and how | it differs from a town. Actually, for us, that distinction isn't relevant either. We use "city" to just mean "local population centre" - whether that's a village, town or "city" in some other nomenclature doesn't matter. All that matters is that it is a location where people live closely enough together that they're all going to set their clocks to the same time. (If some area that people might like to call a city, such as the Coolangatta/Tweed Heads on the Qld/NSW border in Aust, doesn't have the "same time" property, then it is useless for our purposes, and doesn't warrang further consideration, unless perhaps one or more of its time zones is uniquely used in that area) | Does "Greater Milan" have a single governmental authority? That doesn't matter either - the Sydney/Blacktown example would fail if that were the test. The local govt authority for Sydney covers a fairly small area, and while the population there during working hours is fairly high, not very many actually live there, there are plenty of municipalities (with their own local govt) that would have larger populations than the city of Sydney (according to municipal boundaries). Whether Blacktown is the biggest of them or not I have no idea, but it might be. But that's not the Sydney that almost anyone thinks of - even people who live in Blacktown would tell you that they're from Sydney if you ask them, not from Blacktown - not unless you ask "where in Sydney?". Sydney for our purposes includes all its suburbs, and perhaps even (these days) the Illawarra region (Wollongong etc) and maybe even Newcastle (if it doesn't it probably will within a few years). kre From eggert at CS.UCLA.EDU Wed Jul 18 07:26:17 2007 From: eggert at CS.UCLA.EDU (Paul Eggert) Date: Wed, 18 Jul 2007 00:26:17 -0700 Subject: FW: Does UTC+14 Still Exist? In-Reply-To: (Arthur David Olson's message of "Wed\, 27 Jun 2007 08\:20\:36 -0400") References: Message-ID: <87myxurx46.fsf@penguin.cs.ucla.edu> > From: Robert Chapin [mailto:tz at info-svc.com] > Sent: Tuesday, June 26, 2007 10:47 PM > > The latest CIA map doesn't have the UTC+14 time zone on it.. > > https://www.cia.gov/library/publications/the-world-factbook/reference_maps/pdf/time_zones.pdf The previous (2005) CIA map didn't either; see . Perhaps news travels slowly to the CIA? From eggert at CS.UCLA.EDU Wed Jul 18 07:37:28 2007 From: eggert at CS.UCLA.EDU (Paul Eggert) Date: Wed, 18 Jul 2007 00:37:28 -0700 Subject: Geographical boundaries for the continental US tz zones In-Reply-To: <4687DF3F.2080005@adobe.com> (Eric Muller's message of "Sun\, 01 Jul 2007 10\:07\:11 -0700") References: <465E634D.2080301@adobe.com> <4687DF3F.2080005@adobe.com> Message-ID: <87ir8irwlj.fsf@penguin.cs.ucla.edu> Eric Muller writes: > I have completed a first version of a map of the TZ timezones in the US. > It is available as a shapefile at . Thanks. Does the following HTML summarize it accurately?
  • A map of the TZ timezones in the US contains a shapefile of the tz regions in the US.
    • From eggert at CS.UCLA.EDU Wed Jul 18 07:41:28 2007 From: eggert at CS.UCLA.EDU (Paul Eggert) Date: Wed, 18 Jul 2007 00:41:28 -0700 Subject: Geographical boundaries for the continental US tz zones In-Reply-To: (Jesper Norgaard Welen's message of "Sun\, 01 Jul 2007 17\:32\:22 -0500") References: Message-ID: <87ejj6rwev.fsf@penguin.cs.ucla.edu> Jesper Norgaard Welen tried to send the following email to the list on July 1, but apparently didn't get through. I am enclosing it in the hopes that it does get through this time. From: Jesper Norgaard Welen [mailto:jnorgard at prodigy.net.mx] Sent: Domingo, 01 de Julio de 2007 16:15 To: 'tz at elsie.nci.nih.gov' Cc: 'emuller at adobe.com' Subject: RE: Geographical boundaries for the continental US tz zones Hello, Eric Muller I send my comments to your US timezone map directly to the TZ list since I think it could be of common interest in the list and also to urge members to send comments where appropriate. My newest map for World Time Explorer you can download from http://worldtimeexplorer.com/tztables.zip * Navajo/Hopi reservations There is an important Hopi population that you have not included around Latitude 36.14 Longitude -109.40 that I would recommend you to include (see WTE map) * Nevada on Idaho time The city Jackpot in Nevada (and several others like Owyhee and Mountain city) are on Idaho south time, or Denver time if you will. I have included it in a 25 km broad strip of northern Elko county, however just based on common sense when there were cities 12 km below the border that were on Denver time, and I would not expect their time to stop 100 meters outside the city boundary, but note that it is arbitrary, and quite possibly not quite 25 km. Jackpot itself is quite close to the border to Idaho. * Idaho county split (Idaho state) I have a northern and southern part of Idaho county, which I got from another timezone map (possibly Manifold map). This indicates that the southern part of Idaho county is on America/Boise time while the northern part is on America/Los_Angeles. Note that this is *not* documented in the tz database - I am still a bit ambivalent which one to believe. If you want pure tz database functionality, the timezone border should be a little further south. * Alaska I have the same doubts as you. However, I have implemented a solution, however arbitrary it is, seems much better than just putting Juneau for all of Alaska. The Nome area is small, while most of northwestern Alaska is set to Anchorage time. Then there is a Yakutat area and a Juneau area. They are all based on counties in this area. Comments are welcome. * America/Kentucky/Louisville This city belongs to Jefferson county of Kentucky, so I just assumed that this would comprise the Louisville timezone - however tz database needs to describe this - and include more counties if there are more. It just states the vague "part of Kentucky". * Sioux county North Dakota Tz database states "part of Sioux county" and that is exactly what you have included, splitting it around Latitude 46 Longitude -101.34. Where did you get shis from? I have included all Sioux county being on same time, but that most be wrong. * Cherry county Nebraska I see you have a different, more detailed split of Cherry county than mine. Where did you get this from? * Morgan county, Tennessee I recently discovered that this county is on CST/CDT, and included this in the western part of Tennesse. It's around Latitude 36.07 Longitude -84.56 * Alabama Note that (parts of) Chambers, Lee and Russell counties should be on America/New_York time, not on America/Chicago time. * Culberson county, Texas Note that the parts of this county including Nickel creek and Pine Springs are on America/Denver time. Regards, - Jesper N?rgaard Welen -----Original Message----- From: Eric Muller [mailto:emuller at adobe.com] Sent: Domingo, 01 de Julio de 2007 12:07 To: tz at lecserver.nci.nih.gov Subject: Re: Geographical boundaries for the continental US tz zones I have completed a first version of a map of the TZ timezones in the US. It is available as a shapefile at . Comments welcome, Eric. From eggert at CS.UCLA.EDU Wed Jul 18 07:46:19 2007 From: eggert at CS.UCLA.EDU (Paul Eggert) Date: Wed, 18 Jul 2007 00:46:19 -0700 Subject: TimeZones and international waters In-Reply-To: (Christina Lawrence's message of "Sun\, 1 Jul 2007 13\:38\:00 -0500") References: Message-ID: <87abturw6s.fsf@penguin.cs.ucla.edu> "Christina Lawrence" writes: > What distance from shore defines "the territorial waters of any nation"? > Is it nation specific, or an internationally recognized distance from > shore? Sorry, but (like anything involving lawyers :-) it's complicated. Please see for some details. I'll add that URL too, in my next proposed patch. From eggert at CS.UCLA.EDU Wed Jul 18 07:56:19 2007 From: eggert at CS.UCLA.EDU (Paul Eggert) Date: Wed, 18 Jul 2007 00:56:19 -0700 Subject: Daviess, Dubois, Knox, Martin and Pike counties jump thru 1 more hoop Message-ID: <87644irvq4.fsf@penguin.cs.ucla.edu> The DOT yesterday announced a proposed rule that would move the 132,000 residents of Daviess, Dubois, Knox, Martin and Pike counties in Indiana back to Eastern time, effective November 4 (when DST ends this year). The proposed rule has a 30-day public comment period, and then must be approved by the DOT to become final. See the AP article on this subject at . From rlaw at nc.rr.com Wed Jul 18 16:07:45 2007 From: rlaw at nc.rr.com (rlaw at nc.rr.com) Date: Wed, 18 Jul 2007 12:07:45 -0400 Subject: Geographical boundaries for the continental US tz zones Message-ID: ----- Original Message ----- From: Paul Eggert > I send my comments to your US timezone map directly to the TZ list > since I > think it could be of common interest in the list and also to urge > members to > send comments where appropriate. I've put all of my findings about the limits of U.S. time zones (past and present) online at http://www.statoids.com/tus.html. It's all verbal description. For example: > * Idaho county split (Idaho state) > I have a northern and southern part of Idaho county, which I got from > another timezone map (possibly Manifold map). This indicates that the > southern part of Idaho county is on America/Boise time while the > northernpart is on America/Los_Angeles. I have "Idaho county north of the Salmon River" on Pacific Time. > * Sioux county North Dakota > Tz database states "part of Sioux county" and that is exactly what > you have > included, splitting it around Latitude 46 Longitude -101.34. Where > did you > get shis from? I have included all Sioux county being on same time, > but that > most be wrong. I have "Sioux county west of ND route 31" on Mountain Time. Gwillim Law From hellosticky at gmail.com Fri Jul 20 20:36:29 2007 From: hellosticky at gmail.com (Kevin) Date: Fri, 20 Jul 2007 16:36:29 -0400 Subject: Olson tz database tests Message-ID: <6936856c0707201336m479b4476wf0768ad826151586@mail.gmail.com> Hi, is there an existing suite of tests (e.g. unit tests, regression tests, etc.) for the Olson time zone database (to ensure validity, completeness, etc.)? I'm more interested in the logic than the language, although I would prefer C/C++, C#, or Java. Thanks, Kevin From f.de.kruijf at hetnet.nl Sun Jul 22 19:37:53 2007 From: f.de.kruijf at hetnet.nl (Freek de Kruijf) Date: Sun, 22 Jul 2007 13:37:53 -0600 Subject: Timezone of America/Tegucigalpa is wrong Message-ID: <200707221337.54120.f.de.kruijf@hetnet.nl> L.S. The timezone of America/Tegucigalpa includes a Daylight Saving Time. This is wrong. See http://en.wikipedia.org/wiki/Honduras . It is only UTC-6. I can confirm this, while I am there. -- fr.gr. Freek de Kruijf From Susan.Johnson at kronos.com Mon Jul 23 12:37:44 2007 From: Susan.Johnson at kronos.com (Johnson, Susan) Date: Mon, 23 Jul 2007 08:37:44 -0400 Subject: More daylight savings in Australia In-Reply-To: <873b34r8v6.fsf@penguin.cs.ucla.edu> References: <873b34r8v6.fsf@penguin.cs.ucla.edu> Message-ID: <48DD08B024C1A84EA744B144A7ACFB41082AFFCD@exchg-j.KRONOS.COM> Folks, Do we have any official word on what will happen in Western/Southern Australia and when? My Australian office tells me that it now looks like South Australia, NSW, ACT, Victoria, and Tasmania DST changes will occur the first Sunday in April 2008 - instead of the first Sunday in October 2007. All changes are permanent except for South Australia, which will undergo a 'trial' change. --Sue Susan Johnson Manager, Customer Engineering Product Management Kronos Incorporated p: (978) 947-4342 f: (978) 367-5818 www.kronos.com Experts at Improving the Performance of People and Business? -----Original Message----- From: Paul Eggert [mailto:eggert at CS.UCLA.EDU] Sent: Friday, April 13, 2007 4:12 AM To: tz at lecserver.nci.nih.gov Subject: Re: More daylight savings in Australia "Eric Ulevik" writes: > http://www.news.com.au/story/0,23599,21549128-2,00.html Thanks for the heads-up. Today's Sydney Morning Herald reports that South Australia and the Northern Territory (!) may sign up later, but that Western Australia and Queensland will not be involved. Perhaps we should wait a bit to see who falls into line. Also, the SMH says only "it is believed" the dates are as you mentioned. http://www.smh.com.au/articles/2007/04/12/1175971265494.html This is currently listed as the #4 most-viewed article on the Sydney Morning Herald web site. A slow news day? -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 269.3.0/758 - Release Date: 4/12/2007 11:52 AM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.12/910 - Release Date: 7/21/2007 3:52 PM From olsona at dc37a.nci.nih.gov Mon Jul 23 13:37:08 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Mon, 23 Jul 2007 09:37:08 -0400 Subject: FW: Timezone of America/Tegucigalpa is wrong Message-ID: I'm forwarding this message from Freek de Kruijf, who was not on the time zone mailing list at the time it was sent. Freek has since been added. --ado -----Original Message----- From: Freek de Kruijf [mailto:f.de.kruijf at hetnet.nl] Sent: Sunday, July 22, 2007 3:38 To: tz at lecserver.nci.nih.gov Subject: Timezone of America/Tegucigalpa is wrong L.S. The timezone of America/Tegucigalpa includes a Daylight Saving Time. This is wrong. See http://en.wikipedia.org/wiki/Honduras . It is only UTC-6. I can confirm this, while I am there. -- fr.gr. Freek de Kruijf From olsona at dc37a.nci.nih.gov Mon Jul 23 13:38:09 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Mon, 23 Jul 2007 09:38:09 -0400 Subject: FW: More daylight savings in Australia Message-ID: I'm forwarding this message from Susan Johnson, who is on the time zone mailing list at a different address than the one shown below. --ado -----Original Message----- From: Johnson, Susan [mailto:Susan.Johnson at kronos.com] Sent: Monday, July 23, 2007 8:39 To: tz at lecserver.nci.nih.gov Subject: RE: More daylight savings in Australia Folks, Do we have any official word on what will happen in Western/Southern Australia and when? My Australian office tells me that it now looks like South Australia, NSW, ACT, Victoria, and Tasmania DST changes will occur the first Sunday in April 2008 - instead of the first Sunday in October 2007. All changes are permanent except for South Australia, which will undergo a 'trial' change. --Sue Susan Johnson Manager, Customer Engineering Product Management Kronos Incorporated p: (978) 947-4342 f: (978) 367-5818 www.kronos.com Experts at Improving the Performance of People and Business(tm) -----Original Message----- From: Paul Eggert [mailto:eggert at CS.UCLA.EDU] Sent: Friday, April 13, 2007 4:12 AM To: tz at lecserver.nci.nih.gov Subject: Re: More daylight savings in Australia "Eric Ulevik" writes: > http://www.news.com.au/story/0,23599,21549128-2,00.html Thanks for the heads-up. Today's Sydney Morning Herald reports that South Australia and the Northern Territory (!) may sign up later, but that Western Australia and Queensland will not be involved. Perhaps we should wait a bit to see who falls into line. Also, the SMH says only "it is believed" the dates are as you mentioned. http://www.smh.com.au/articles/2007/04/12/1175971265494.html This is currently listed as the #4 most-viewed article on the Sydney Morning Herald web site. A slow news day? -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 269.3.0/758 - Release Date: 4/12/2007 11:52 AM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.12/910 - Release Date: 7/21/2007 3:52 PM From olsona at dc37a.nci.nih.gov Mon Jul 23 15:34:10 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Mon, 23 Jul 2007 11:34:10 -0400 Subject: Olson tz database tests In-Reply-To: <6936856c0707201336m479b4476wf0768ad826151586@mail.gmail.com> References: <6936856c0707201336m479b4476wf0768ad826151586@mail.gmail.com> Message-ID: The only thing I've got is the shell script below (known as "zgress" locally). --ado #!/bin/sh # Accept the names of two time zone package source directories (A and B). # Do a "make install" from each directory to temporary directories. # Apply the created "zdump" programs to all the created binary data files: # the A zdump to the A data (yielding AA results) # the A zdump to the B data (yielding AB results) # the B zdump to the A data (yielding BA results) # the B zdump to the B data (yielding BB results) # Report on differences. O=`basename "$0"` case $# in 2) ;; *) echo "$O: usage is $O atzsourcedir btzsourcedir" 1>&2 exit 1 ;; esac T=/tmp/,zgress$$ trap 'rm -f -r $T*' 0 1 2 3 15 # Step 1: do "make"s for both the A and B versions for pass in a b do ( cd "$1"; make clean; make install TOPDIR=$T$pass ) || exit 1 shift done # Step 2: apply both the A and B zdumps to both the A and B data for prog in a b do for data in a b do zdump=$T$prog/etc/zdump zoneinfo=$T$data/etc/zoneinfo $zdump -v `find $zoneinfo ! -type d -print | sort` 2>&- | sed "s@$zoneinfo/@@" > $T$prog$data done done # Step 3: do comparisons ls -l $T[ab][ab] left=aa for right in ab ba bb do diff $T$left $T$right | sed "s/^/$left vs. $right:/" done From eggert at CS.UCLA.EDU Mon Jul 23 23:07:48 2007 From: eggert at CS.UCLA.EDU (Paul Eggert) Date: Mon, 23 Jul 2007 16:07:48 -0700 Subject: Timezone of America/Tegucigalpa is wrong In-Reply-To: (Arthur David Olson's message of "Mon\, 23 Jul 2007 09\:37\:08 -0400") References: Message-ID: <87tzrulnwb.fsf@penguin.cs.ucla.edu> > From: Freek de Kruijf [mailto:f.de.kruijf at hetnet.nl] > Sent: Sunday, July 22, 2007 3:38 > > The timezone of America/Tegucigalpa includes a Daylight Saving Time. > This is wrong. See http://en.wikipedia.org/wiki/Honduras . It is > only UTC-6. I can confirm this, while I am there. Thanks. No need to confirm it; the latest version of the tz database already has this. You can get it from . It reports that Honduras observed DST in 1987/1988 and in 2006 (only). From eggert at CS.UCLA.EDU Mon Jul 23 23:46:25 2007 From: eggert at CS.UCLA.EDU (Paul Eggert) Date: Mon, 23 Jul 2007 16:46:25 -0700 Subject: FW: More daylight savings in Australia In-Reply-To: (Arthur David Olson's message of "Mon\, 23 Jul 2007 09\:38\:09 -0400") References: Message-ID: <87ps2ilm3y.fsf@penguin.cs.ucla.edu> > From: Johnson, Susan [mailto:Susan.Johnson at kronos.com] > Sent: Monday, July 23, 2007 8:39 > > My Australian office tells me that it now looks like South Australia, > NSW, ACT, Victoria, and Tasmania DST changes will occur the first Sunday > in April 2008 - instead of the first Sunday in October 2007. All > changes are permanent except for South Australia, which will undergo a > 'trial' change. Yes, that matches my understanding as well. Here are some changes that I plan to put into my next proposed set. These aren't "official" yet (as if anything in tz were "official" :-) but should give you a heads-up. --- australasia 2007/05/07 14:46:15 2007.6 +++ australasia 2007/07/23 23:23:07 @@ -79,7 +79,7 @@ Zone Australia/Lindeman 9:55:56 - LMT 1 # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule AS 1971 1985 - Oct lastSun 2:00s 1:00 - Rule AS 1986 only - Oct 19 2:00s 1:00 - -Rule AS 1987 max - Oct lastSun 2:00s 1:00 - +Rule AS 1987 2007 - Oct lastSun 2:00s 1:00 - Rule AS 1972 only - Feb 27 2:00s 0 - Rule AS 1973 1985 - Mar Sun>=1 2:00s 0 - Rule AS 1986 1989 - Mar Sun>=15 2:00s 0 - @@ -90,7 +90,9 @@ Rule AS 1993 only - Mar Sun>=1 2:00s 0 - Rule AS 1994 only - Mar Sun>=18 2:00s 0 - Rule AS 1995 2005 - Mar lastSun 2:00s 0 - Rule AS 2006 only - Apr Sun>=1 2:00s 0 - -Rule AS 2007 max - Mar lastSun 2:00s 0 - +Rule AS 2007 only - Mar lastSun 2:00s 0 - +Rule AS 2008 max - Apr Sun>=1 2:00s 0 - +Rule AS 2008 max - Oct Sun>=1 2:00s 1:00 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Adelaide 9:14:20 - LMT 1895 Feb 9:00 - CST 1899 May @@ -121,7 +123,8 @@ Rule AT 1991 2005 - Mar lastSun 2:00s 0 Rule AT 2000 only - Aug lastSun 2:00s 1:00 - Rule AT 2001 max - Oct Sun>=1 2:00s 1:00 - Rule AT 2006 only - Apr Sun>=1 2:00s 0 - -Rule AT 2007 max - Mar lastSun 2:00s 0 - +Rule AT 2007 only - Mar lastSun 2:00s 0 - +Rule AT 2008 max - Apr Sun>=1 2:00s 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Hobart 9:49:16 - LMT 1895 Sep 10:00 - EST 1916 Oct 1 2:00 @@ -145,9 +148,11 @@ Rule AV 1988 1999 - Oct lastSun 2:00s 1: Rule AV 1991 1994 - Mar Sun>=1 2:00s 0 - Rule AV 1995 2005 - Mar lastSun 2:00s 0 - Rule AV 2000 only - Aug lastSun 2:00s 1:00 - -Rule AV 2001 max - Oct lastSun 2:00s 1:00 - +Rule AV 2001 2007 - Oct lastSun 2:00s 1:00 - Rule AV 2006 only - Apr Sun>=1 2:00s 0 - -Rule AV 2007 max - Mar lastSun 2:00s 0 - +Rule AV 2007 only - Mar lastSun 2:00s 0 - +Rule AV 2008 max - Apr Sun>=1 2:00s 0 - +Rule AV 2008 max - Oct Sun>=1 2:00s 1:00 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Melbourne 9:39:52 - LMT 1895 Feb 10:00 Aus EST 1971 @@ -166,9 +171,11 @@ Rule AN 1987 1999 - Oct lastSun 2:00s 1: Rule AN 1990 1995 - Mar Sun>=1 2:00s 0 - Rule AN 1996 2005 - Mar lastSun 2:00s 0 - Rule AN 2000 only - Aug lastSun 2:00s 1:00 - -Rule AN 2001 max - Oct lastSun 2:00s 1:00 - +Rule AN 2001 2007 - Oct lastSun 2:00s 1:00 - Rule AN 2006 only - Apr Sun>=1 2:00s 0 - -Rule AN 2007 max - Mar lastSun 2:00s 0 - +Rule AN 2007 only - Mar lastSun 2:00s 0 - +Rule AN 2008 max - Apr Sun>=1 2:00s 0 - +Rule AN 2008 max - Oct Sun>=1 2:00s 1:00 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Sydney 10:04:52 - LMT 1895 Feb 10:00 Aus EST 1971 @@ -191,9 +198,11 @@ Rule LH 1987 1999 - Oct lastSun 2:00 0:3 Rule LH 1990 1995 - Mar Sun>=1 2:00 0 - Rule LH 1996 2005 - Mar lastSun 2:00 0 - Rule LH 2000 only - Aug lastSun 2:00 0:30 - -Rule LH 2001 max - Oct lastSun 2:00 0:30 - +Rule LH 2001 2007 - Oct lastSun 2:00 0:30 - Rule LH 2006 only - Apr Sun>=1 2:00 0 - -Rule LH 2007 max - Mar lastSun 2:00 0 - +Rule LH 2007 only - Mar lastSun 2:00 0 - +Rule LH 2008 max - Apr Sun>=1 2:00 0 - +Rule LH 2008 max - Oct Sun>=1 2:00 0:30 - Zone Australia/Lord_Howe 10:36:20 - LMT 1895 Feb 10:00 - EST 1981 Mar 10:30 LH LHST From cppcraze at gmail.com Fri Jul 27 04:55:30 2007 From: cppcraze at gmail.com (Martin Dong) Date: Fri, 27 Jul 2007 12:55:30 +0800 Subject: How to support such capabilites based on current Olson Time Zone implementation Message-ID: Dear All in this maillist, We have been investigating the feasibility of migrating Olson Time Zone Database to our system. Given that our system is Linux-based, we can just use tzcode implementation or Glibc functions because Glibc has adopted Olson implementation to some extent. But according to our basic and existing requirements, I have met some problems that I think are hard for me: - How to get the local time of different region or city at the same time? The basic requirement is to display the local time of different region or city at the same time. After some study of Olson implementation, I knew function "localtime" will handle everything, parsing tzfile and doing the conversion from utc to local time. The correct local time can be gotten through a simple invocation to "localtime". But "localtime" assumes the Sytem Local Time Zone is set in environmental variable "TZ" or from the Standard TimeZone file "/etc/localtime" if "TZ" is not defined in the process. In this case, how can a caller get the local time of some city which is not the System Local Time Zone? It seems we must change "TZ" or the Standard TimeZone file before calling "localtime" to get another city's local time because "localtime" doesn't take such an argument that can let caller specify a time zone, which means "localtime" can return the local time related to either the System Local Time Zone or the time zone user specifies. Although I know there're so many applications which already integrates the Olson Database and they have realized my above requirement "display multiple local time at the same time", I don't know how they make it. - How to get the notification of DST status change as time elaspes? This problem is out of our another requirement that we need to inform other components in our system of the DST status change in various conditions, such as changing time may lead to DST change, changing local time zone may lead to DST change, and as time elapsing, etc. The former two behaviors are user-active ones, we can track the change easily, but the problem is the last one, it's the system automatic behavior, our of the control of user. In this case, the system needs some CALLBACK ability to capture this change and further broadcast it. For our system, there's an Alarm Server that can provide timer machinasm. We will parse our own time zone database and get the next nearest DST transition time and add it to Alarm Server, then when the timer is time out, Alarm Server will trigger a CALLBACK function to further process. But it seems Olson is lack of such capability. After thinking from another perpsective, if we can get the next nearest DST transition time through Olson Time Zone database, we can still utilize our current Alarm Server. But it's still a problem how to get the next nearest DST transition time through the current Olson implementation because all the implementation is hiden behind "localtime". In all the public functions, there's no such one which can support getting the DST transition time. I don't have any good idea in mind right now. Should I make some modification to Olson to add such capability, or other way i could go? I will very much appreciate if any of you can give me some hints about above problems. Thank you in advance. Best Regards, -Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmorrow at sendwordnow.com Fri Jul 27 06:28:40 2007 From: jmorrow at sendwordnow.com (John B. Morrow) Date: Fri, 27 Jul 2007 02:28:40 -0400 Subject: Does zic currently compile time zone abbreviations correctly? Message-ID: <8C509380F5C1E64686251D030FA286E0A1DE40@LATSVIVEX01.sendwordnow.local> In the process of extracting time zone information from the zoneinfo database, I noticed that the abbreviation pointer break for quite a few time zones including Europe/London, Asia/Dubai, and quite a few others. The problem seems to be in the compiled time zone files so I spent some time looking at zic. What seems to be happening is that zic uses some criteria to determine of the abbreviation (and other info for types) is used and won't write it if it thinks it isn't needed. The problem is that it doesn't adjust the indexes (tt_abbrind) that reference those abbreviations, so they'll point to bad data or empty strings. My quick (and admittedly heavy handed fix) was to force zic to write all of the abbreviations, whether they are necessary or not. If this really is a problem, it should probably be fixed at some point. Please note that the data in our fairly recently updated Linux server has abbreviations that don't seem to work. If I'm missing something or there is some other way more correct way to reference the abbreviations, please let me know. I'm using tt_abbrind as per the tzfile man page and the tzcode2007f.tar.gz sources. John Morrow -------------- next part -------------- An HTML attachment was scrubbed... URL: From olsona at dc37a.nci.nih.gov Fri Jul 27 15:20:33 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Fri, 27 Jul 2007 11:20:33 -0400 Subject: FW: Does zic currently compile time zone abbreviations correctly? Message-ID: I'm forwarding this message from John B. Morrow, who is not on the time zone mailing list. Those of you who are on the time zone mailing list should direct replies appropriately. --ado From: John B. Morrow [mailto:jmorrow at sendwordnow.com] Sent: Friday, July 27, 2007 2:29 AM To: tz at lecserver.nci.nih.gov Subject: Does zic currently compile time zone abbreviations correctly? In the process of extracting time zone information from the zoneinfo database, I noticed that the abbreviation pointer break for quite a few time zones including Europe/London, Asia/Dubai, and quite a few others.? The problem seems to be in the compiled time zone files so I spent some time looking at zic.? What seems to be happening is that zic uses some criteria to determine of the abbreviation (and other info for types) is used and won't write it if it thinks it isn't needed.? The problem is that it doesn't adjust the indexes (tt_abbrind) that reference those abbreviations, so they'll point to bad data or empty strings.? My quick (and admittedly heavy handed fix) was to force zic to write all of the abbreviations, whether they are necessary or not.? If this really is a problem, it should probably be fixed at some point.? Please note that the data in our fairly recently updated Linux server has abbreviations that don't seem to work. If I'm missing something or there is some other way more correct way to reference the abbreviations, please let me know.? I'm using tt_abbrind as per the tzfile man page and the tzcode2007f.tar.gz sources. John Morrow From olsona at dc37a.nci.nih.gov Fri Jul 27 15:29:03 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Fri, 27 Jul 2007 11:29:03 -0400 Subject: Does zic currently compile time zone abbreviations correctly? In-Reply-To: References: Message-ID: The typescript below seems to indicate that there's nothing amiss with Europe/London; do you get different results if you run "tzhead"? --ado Script started on Fri 27 Jul 2007 11:24:37 AM EDT lecserver$ cat tzhead.c #include "private.h" struct tzhead { char tzh_magic[4]; /* TZ_MAGIC */ char tzh_version[1]; /* '\0' or '2' as of 2005 */ char tzh_reserved[15]; /* reserved--must be zero */ char tzh_ttisgmtcnt[4]; /* coded number of trans. time flags */ char tzh_ttisstdcnt[4]; /* coded number of trans. time flags */ char tzh_leapcnt[4]; /* coded number of leap seconds */ char tzh_timecnt[4]; /* coded number of transition times */ char tzh_typecnt[4]; /* coded number of local time types */ char tzh_charcnt[4]; /* coded number of abbr. chars */ }; static char * progname; static long long detzcode64(codep) const char * const codep; { register long long result; register int i; result = (codep[0] & 0x80) ? ~0L : 0L; for (i = 0; i < 8; ++i) result = result * 256 + (codep[i] & 0xff); return result; } static long long detzcode(codep) const char * const codep; { register long result; register int i; result = (codep[0] & 0x80) ? ~0L : 0L; for (i = 0; i < 4; ++i) result = (result << 8) | (codep[i] & 0xff); return result; } static void wild2exit(cp, dp) { (void) fprintf(stderr, "%s: wild result %s %s\n", progname, cp, dp); exit(1); } static void handle(filename) char * filename; { FILE * fp; struct tzhead tzh; long long ll; char c; int i; int pass; long ttisgmtcnt; long ttisstdcnt; long leapcnt; long timecnt; long typecnt; long charcnt; char buf[8]; struct tm tm; fp = fopen(filename, "r"); if (fp == NULL) wild2exit("result opening", filename); for (pass = 1; pass <= 2; ++pass) { if (fread(&tzh, sizeof tzh, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tversion\t", filename); c = tzh.tzh_version[0]; if (isascii(c) && isprint(c)) (void) putchar(c); else (void) printf("\\%o", c); (void) putchar('\n'); ttisgmtcnt = detzcode(tzh.tzh_ttisgmtcnt); ttisstdcnt = detzcode(tzh.tzh_ttisstdcnt); leapcnt = detzcode(tzh.tzh_leapcnt); timecnt = detzcode(tzh.tzh_timecnt); typecnt = detzcode(tzh.tzh_typecnt); charcnt = detzcode(tzh.tzh_charcnt); (void) printf("%s\tttisgmtcnt\t%ld\n", filename, ttisgmtcnt); (void) printf("%s\tttisstdcnt\t%ld\n", filename, ttisstdcnt); (void) printf("%s\tleapcnt\t%ld\n", filename, leapcnt); (void) printf("%s\ttimecnt\t%ld\n", filename, timecnt); (void) printf("%s\ttypecnt\t%ld\n", filename, typecnt); (void) printf("%s\tcharcnt\t%ld\n", filename, charcnt); for (i = 0; i < timecnt; ++i) { if (fread(buf, pass * 4, 1, fp) != 1) wild2exit("result reading", filename); ll = (pass == 1) ? detzcode(buf) : detzcode64(buf); { time_t l; l = ll; tm = *gmtime(&l); } (void) printf("%s\ttime[%d]\t%lld\t%s", filename, i, ll, asctime(&tm)); } for (i = 0; i < timecnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\ttype[%d]\t%d\n", filename, i, buf[0]); } for (i = 0; i < typecnt; ++i) { long l; if (fread(buf, 4, 1, fp) != 1) wild2exit("result reading", filename); l = detzcode(buf); (void) printf("%s\ttype[%d].offset\t%ld\n", filename, i, l); if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\ttype[%d].isdst\t%ld\n", filename, i, buf[0]); if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\ttype[%d].abbrind\t%ld\n", filename, i, buf[0]); } for (i = 0; i < charcnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tabbr[%d]\t", filename, i); if (isascii(buf[0]) && isprint(buf[0])) (void) printf("%c", buf[0]); else if (buf[0] == '\0') (void) printf("\\0"); else (void) printf("\%03o", buf[0]); (void) printf("\n"); } for (i = 0; i < ttisstdcnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tisstd[%d]\t%d\n", filename, i, buf[0]); } for (i = 0; i < ttisgmtcnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tisgmt[%d]\t%d\n", filename, i, buf[0]); } if (tzh.tzh_version[0] != '2') break; } if (fclose(fp) != 0) { (void) fprintf(stderr, "%s: wild result closing %s\n", progname, filename); exit(1); } } int main(argc, argv) int argc; char * argv[]; { int i; progname = argv[0]; for (i = 1; i < argc; ++i) handle(argv[i]); exit(0); } lecserver$ make tzhead cc -DTZDIR=\"/usr/local/etc/zoneinfo\" tzhead.c -o tzhead lecserver$ tzhead tmp/etc/zoneinfo/Europe/London | grep abbr tmp/etc/zoneinfo/Europe/London type[0].abbrind 0 tmp/etc/zoneinfo/Europe/London type[1].abbrind 4 tmp/etc/zoneinfo/Europe/London type[2].abbrind 8 tmp/etc/zoneinfo/Europe/London type[3].abbrind 0 tmp/etc/zoneinfo/Europe/London type[4].abbrind 0 tmp/etc/zoneinfo/Europe/London type[5].abbrind 4 tmp/etc/zoneinfo/Europe/London type[6].abbrind 4 tmp/etc/zoneinfo/Europe/London abbr[0] B tmp/etc/zoneinfo/Europe/London abbr[1] S tmp/etc/zoneinfo/Europe/London abbr[2] T tmp/etc/zoneinfo/Europe/London abbr[3] \0 tmp/etc/zoneinfo/Europe/London abbr[4] G tmp/etc/zoneinfo/Europe/London abbr[5] M tmp/etc/zoneinfo/Europe/London abbr[6] T tmp/etc/zoneinfo/Europe/London abbr[7] \0 tmp/etc/zoneinfo/Europe/London abbr[8] B tmp/etc/zoneinfo/Europe/London abbr[9] D tmp/etc/zoneinfo/Europe/London abbr[10] S tmp/etc/zoneinfo/Europe/London abbr[11] T tmp/etc/zoneinfo/Europe/London abbr[12] \0 tmp/etc/zoneinfo/Europe/London type[0].abbrind 0 tmp/etc/zoneinfo/Europe/London type[1].abbrind 4 tmp/etc/zoneinfo/Europe/London type[2].abbrind 8 tmp/etc/zoneinfo/Europe/London type[3].abbrind 12 tmp/etc/zoneinfo/Europe/London type[4].abbrind 4 tmp/etc/zoneinfo/Europe/London type[5].abbrind 4 tmp/etc/zoneinfo/Europe/London type[6].abbrind 8 tmp/etc/zoneinfo/Europe/London type[7].abbrind 8 tmp/etc/zoneinfo/Europe/London abbr[0] L tmp/etc/zoneinfo/Europe/London abbr[1] M tmp/etc/zoneinfo/Europe/London abbr[2] T tmp/etc/zoneinfo/Europe/London abbr[3] \0 tmp/etc/zoneinfo/Europe/London abbr[4] B tmp/etc/zoneinfo/Europe/London abbr[5] S tmp/etc/zoneinfo/Europe/London abbr[6] T tmp/etc/zoneinfo/Europe/London abbr[7] \0 tmp/etc/zoneinfo/Europe/London abbr[8] G tmp/etc/zoneinfo/Europe/London abbr[9] M tmp/etc/zoneinfo/Europe/London abbr[10] T tmp/etc/zoneinfo/Europe/London abbr[11] \0 tmp/etc/zoneinfo/Europe/London abbr[12] B tmp/etc/zoneinfo/Europe/London abbr[13] D tmp/etc/zoneinfo/Europe/London abbr[14] S tmp/etc/zoneinfo/Europe/London abbr[15] T tmp/etc/zoneinfo/Europe/London abbr[16] \0 lecserver$ exit script done on Fri 27 Jul 2007 11:25:04 AM EDT From: John B. Morrow [mailto:jmorrow at sendwordnow.com] Sent: Friday, July 27, 2007 2:29 AM To: tz at lecserver.nci.nih.gov Subject: Does zic currently compile time zone abbreviations correctly? In the process of extracting time zone information from the zoneinfo database, I noticed that the abbreviation pointer break for quite a few time zones including Europe/London, Asia/Dubai, and quite a few others.? The problem seems to be in the compiled time zone files so I spent some time looking at zic.? What seems to be happening is that zic uses some criteria to determine of the abbreviation (and other info for types) is used and won't write it if it thinks it isn't needed.? The problem is that it doesn't adjust the indexes (tt_abbrind) that reference those abbreviations, so they'll point to bad data or empty strings.? My quick (and admittedly heavy handed fix) was to force zic to write all of the abbreviations, whether they are necessary or not.? If this really is a problem, it should probably be fixed at some point.? Please note that the data in our fairly recently updated Linux server has abbreviations that don't seem to work. If I'm missing something or there is some other way more correct way to reference the abbreviations, please let me know.? I'm using tt_abbrind as per the tzfile man page and the tzcode2007f.tar.gz sources. John Morrow From olsona at dc37a.nci.nih.gov Fri Jul 27 15:32:31 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Fri, 27 Jul 2007 11:32:31 -0400 Subject: FW: How to support such capabilites based on current Olson Time Zone implementation Message-ID: I'm forwarding this message from Martin Dong, who is not on the time zone mailing list. Those of you who are on the time zone mailing list should direct replies appropriately. --ado From: Martin Dong [mailto:cppcraze at gmail.com] Sent: Friday, July 27, 2007 12:56 AM To: tz at lecserver.nci.nih.gov Subject: How to support such capabilites based on current Olson Time Zone implementation Dear All in this maillist, ? We have been investigating the feasibility of migrating Olson Time Zone Database to our system. Given that our system is Linux-based, we can just use tzcode implementation or Glibc functions because Glibc has adopted Olson implementation to some extent. But according to our basic and?existing requirements, I have met some problems that I think are hard for me: * How to get the local time of different region or city at the same time? The basic requirement is to display the local time of different region or city at the same time. After some study of Olson implementation, I knew function "localtime" will handle everything, parsing tzfile and doing the conversion from utc to local time. The correct local?time can be gotten through a simple invocation to "localtime". But "localtime" assumes the Sytem Local Time Zone is set in environmental variable "TZ" or from the Standard TimeZone file "/etc/localtime" if "TZ" is not defined in the process. In this case, how can?a caller get the local?time of some city which is not the System Local Time Zone? It seems we must change "TZ" or the Standard TimeZone file before calling "localtime" to get another city's local time because "localtime" doesn't take such an argument that can let caller specify a time zone, which means "localtime" can return the local time related to either the System Local Time Zone or the time zone user specifies. ? Although I know there're so many applications?which already integrates the Olson Database and they have realized my?above requirement "display multiple local time at the same time", I don't know how they make it.? * How to get the notification of DST status change as time elaspes? This problem is out of our another requirement that we need to inform other components in our system of the DST status change in various conditions, such as changing time may lead to DST change, changing local time zone may lead to DST change, and as time elapsing, etc. The former two behaviors are user-active ones, we can track the change easily, but the problem is the last one, it's the system automatic behavior, our of the control of user. In this case, the system needs some CALLBACK ability to capture this change and further broadcast it. For our system, there's an Alarm Server that can provide timer machinasm. We will parse our own time zone database and get the next nearest DST transition time and add it to Alarm Server, then when the timer is time out, Alarm Server will trigger a CALLBACK function to further process. ? But it seems Olson is lack of such capability. After thinking from another perpsective, if we can get the next nearest DST transition time through Olson Time Zone database, we can still utilize our current Alarm Server. But it's still a problem how to get the next nearest DST transition time through the current Olson implementation because all the implementation is hiden behind "localtime". In all the public functions, there's no such one which can support getting the DST transition time. ? I don't have any good idea in mind right now. Should I make some modification to Olson to add such capability, or other way i could go? I will very much appreciate if any of you can give me some hints about above problems. Thank you in advance. ? Best Regards, ? -Martin From jmorrow at sendwordnow.com Fri Jul 27 16:18:58 2007 From: jmorrow at sendwordnow.com (John B. Morrow) Date: Fri, 27 Jul 2007 12:18:58 -0400 Subject: Does zic currently compile time zone abbreviations correctly? References: Message-ID: <8C509380F5C1E64686251D030FA286E0A1DF52@LATSVIVEX01.sendwordnow.local> This response and program was very helpful. Apparently I was missing the level of indirection that converted the type in the ttinfo into an abbrind to look up the abbreviation. For some time zones, that was fine and for others it wasn't. Now that I've added that additional level in, my program seems to be working correctly. Thank you for your quick response. John Morrow -----Original Message----- From: Olson, Arthur David (NIH/NCI) [E] [mailto:olsona at dc37a.nci.nih.gov] Sent: Friday, July 27, 2007 11:29 AM To: tz at elsie.nci.nih.gov Cc: John B. Morrow Subject: RE: Does zic currently compile time zone abbreviations correctly? The typescript below seems to indicate that there's nothing amiss with Europe/London; do you get different results if you run "tzhead"? --ado Script started on Fri 27 Jul 2007 11:24:37 AM EDT lecserver$ cat tzhead.c #include "private.h" struct tzhead { char tzh_magic[4]; /* TZ_MAGIC */ char tzh_version[1]; /* '\0' or '2' as of 2005 */ char tzh_reserved[15]; /* reserved--must be zero */ char tzh_ttisgmtcnt[4]; /* coded number of trans. time flags */ char tzh_ttisstdcnt[4]; /* coded number of trans. time flags */ char tzh_leapcnt[4]; /* coded number of leap seconds */ char tzh_timecnt[4]; /* coded number of transition times */ char tzh_typecnt[4]; /* coded number of local time types */ char tzh_charcnt[4]; /* coded number of abbr. chars */ }; static char * progname; static long long detzcode64(codep) const char * const codep; { register long long result; register int i; result = (codep[0] & 0x80) ? ~0L : 0L; for (i = 0; i < 8; ++i) result = result * 256 + (codep[i] & 0xff); return result; } static long long detzcode(codep) const char * const codep; { register long result; register int i; result = (codep[0] & 0x80) ? ~0L : 0L; for (i = 0; i < 4; ++i) result = (result << 8) | (codep[i] & 0xff); return result; } static void wild2exit(cp, dp) { (void) fprintf(stderr, "%s: wild result %s %s\n", progname, cp, dp); exit(1); } static void handle(filename) char * filename; { FILE * fp; struct tzhead tzh; long long ll; char c; int i; int pass; long ttisgmtcnt; long ttisstdcnt; long leapcnt; long timecnt; long typecnt; long charcnt; char buf[8]; struct tm tm; fp = fopen(filename, "r"); if (fp == NULL) wild2exit("result opening", filename); for (pass = 1; pass <= 2; ++pass) { if (fread(&tzh, sizeof tzh, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tversion\t", filename); c = tzh.tzh_version[0]; if (isascii(c) && isprint(c)) (void) putchar(c); else (void) printf("\\%o", c); (void) putchar('\n'); ttisgmtcnt = detzcode(tzh.tzh_ttisgmtcnt); ttisstdcnt = detzcode(tzh.tzh_ttisstdcnt); leapcnt = detzcode(tzh.tzh_leapcnt); timecnt = detzcode(tzh.tzh_timecnt); typecnt = detzcode(tzh.tzh_typecnt); charcnt = detzcode(tzh.tzh_charcnt); (void) printf("%s\tttisgmtcnt\t%ld\n", filename, ttisgmtcnt); (void) printf("%s\tttisstdcnt\t%ld\n", filename, ttisstdcnt); (void) printf("%s\tleapcnt\t%ld\n", filename, leapcnt); (void) printf("%s\ttimecnt\t%ld\n", filename, timecnt); (void) printf("%s\ttypecnt\t%ld\n", filename, typecnt); (void) printf("%s\tcharcnt\t%ld\n", filename, charcnt); for (i = 0; i < timecnt; ++i) { if (fread(buf, pass * 4, 1, fp) != 1) wild2exit("result reading", filename); ll = (pass == 1) ? detzcode(buf) : detzcode64(buf); { time_t l; l = ll; tm = *gmtime(&l); } (void) printf("%s\ttime[%d]\t%lld\t%s", filename, i, ll, asctime(&tm)); } for (i = 0; i < timecnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\ttype[%d]\t%d\n", filename, i, buf[0]); } for (i = 0; i < typecnt; ++i) { long l; if (fread(buf, 4, 1, fp) != 1) wild2exit("result reading", filename); l = detzcode(buf); (void) printf("%s\ttype[%d].offset\t%ld\n", filename, i, l); if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\ttype[%d].isdst\t%ld\n", filename, i, buf[0]); if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\ttype[%d].abbrind\t%ld\n", filename, i, buf[0]); } for (i = 0; i < charcnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tabbr[%d]\t", filename, i); if (isascii(buf[0]) && isprint(buf[0])) (void) printf("%c", buf[0]); else if (buf[0] == '\0') (void) printf("\\0"); else (void) printf("\%03o", buf[0]); (void) printf("\n"); } for (i = 0; i < ttisstdcnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tisstd[%d]\t%d\n", filename, i, buf[0]); } for (i = 0; i < ttisgmtcnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tisgmt[%d]\t%d\n", filename, i, buf[0]); } if (tzh.tzh_version[0] != '2') break; } if (fclose(fp) != 0) { (void) fprintf(stderr, "%s: wild result closing %s\n", progname, filename); exit(1); } } int main(argc, argv) int argc; char * argv[]; { int i; progname = argv[0]; for (i = 1; i < argc; ++i) handle(argv[i]); exit(0); } lecserver$ make tzhead cc -DTZDIR=\"/usr/local/etc/zoneinfo\" tzhead.c -o tzhead lecserver$ tzhead tmp/etc/zoneinfo/Europe/London | grep abbr tmp/etc/zoneinfo/Europe/London type[0].abbrind 0 tmp/etc/zoneinfo/Europe/London type[1].abbrind 4 tmp/etc/zoneinfo/Europe/London type[2].abbrind 8 tmp/etc/zoneinfo/Europe/London type[3].abbrind 0 tmp/etc/zoneinfo/Europe/London type[4].abbrind 0 tmp/etc/zoneinfo/Europe/London type[5].abbrind 4 tmp/etc/zoneinfo/Europe/London type[6].abbrind 4 tmp/etc/zoneinfo/Europe/London abbr[0] B tmp/etc/zoneinfo/Europe/London abbr[1] S tmp/etc/zoneinfo/Europe/London abbr[2] T tmp/etc/zoneinfo/Europe/London abbr[3] \0 tmp/etc/zoneinfo/Europe/London abbr[4] G tmp/etc/zoneinfo/Europe/London abbr[5] M tmp/etc/zoneinfo/Europe/London abbr[6] T tmp/etc/zoneinfo/Europe/London abbr[7] \0 tmp/etc/zoneinfo/Europe/London abbr[8] B tmp/etc/zoneinfo/Europe/London abbr[9] D tmp/etc/zoneinfo/Europe/London abbr[10] S tmp/etc/zoneinfo/Europe/London abbr[11] T tmp/etc/zoneinfo/Europe/London abbr[12] \0 tmp/etc/zoneinfo/Europe/London type[0].abbrind 0 tmp/etc/zoneinfo/Europe/London type[1].abbrind 4 tmp/etc/zoneinfo/Europe/London type[2].abbrind 8 tmp/etc/zoneinfo/Europe/London type[3].abbrind 12 tmp/etc/zoneinfo/Europe/London type[4].abbrind 4 tmp/etc/zoneinfo/Europe/London type[5].abbrind 4 tmp/etc/zoneinfo/Europe/London type[6].abbrind 8 tmp/etc/zoneinfo/Europe/London type[7].abbrind 8 tmp/etc/zoneinfo/Europe/London abbr[0] L tmp/etc/zoneinfo/Europe/London abbr[1] M tmp/etc/zoneinfo/Europe/London abbr[2] T tmp/etc/zoneinfo/Europe/London abbr[3] \0 tmp/etc/zoneinfo/Europe/London abbr[4] B tmp/etc/zoneinfo/Europe/London abbr[5] S tmp/etc/zoneinfo/Europe/London abbr[6] T tmp/etc/zoneinfo/Europe/London abbr[7] \0 tmp/etc/zoneinfo/Europe/London abbr[8] G tmp/etc/zoneinfo/Europe/London abbr[9] M tmp/etc/zoneinfo/Europe/London abbr[10] T tmp/etc/zoneinfo/Europe/London abbr[11] \0 tmp/etc/zoneinfo/Europe/London abbr[12] B tmp/etc/zoneinfo/Europe/London abbr[13] D tmp/etc/zoneinfo/Europe/London abbr[14] S tmp/etc/zoneinfo/Europe/London abbr[15] T tmp/etc/zoneinfo/Europe/London abbr[16] \0 lecserver$ exit script done on Fri 27 Jul 2007 11:25:04 AM EDT From: John B. Morrow [mailto:jmorrow at sendwordnow.com] Sent: Friday, July 27, 2007 2:29 AM To: tz at lecserver.nci.nih.gov Subject: Does zic currently compile time zone abbreviations correctly? In the process of extracting time zone information from the zoneinfo database, I noticed that the abbreviation pointer break for quite a few time zones including Europe/London, Asia/Dubai, and quite a few others.? The problem seems to be in the compiled time zone files so I spent some time looking at zic.? What seems to be happening is that zic uses some criteria to determine of the abbreviation (and other info for types) is used and won't write it if it thinks it isn't needed.? The problem is that it doesn't adjust the indexes (tt_abbrind) that reference those abbreviations, so they'll point to bad data or empty strings.? My quick (and admittedly heavy handed fix) was to force zic to write all of the abbreviations, whether they are necessary or not.? If this really is a problem, it should probably be fixed at some point.? Please note that the data in our fairly recently updated Linux server has abbreviations that don't seem to work. If I'm missing something or there is some other way more correct way to reference the abbreviations, please let me know.? I'm using tt_abbrind as per the tzfile man page and the tzcode2007f.tar.gz sources. John Morrow From markus.icu at gmail.com Fri Jul 27 18:38:00 2007 From: markus.icu at gmail.com (Markus Scherer) Date: Fri, 27 Jul 2007 11:38:00 -0700 Subject: FW: How to support such capabilites based on current Olson Time Zone implementation In-Reply-To: References: Message-ID: <6bb028490707271138x31eaae4es8d2cac06354bd4b6@mail.gmail.com> Dear Martin, For at least the first requirement, you might want to try other time zone support libraries listed on this list's homepage [1], for example ICU [2]. You could also send an email to the icu-support mailing list [3] to see if your second can be provided for. [1] http://www.twinsun.com/tz/tz-link.htm [2] http://icu-project.org/ [3] http://icu-project.org/contacts.html Best regards, markus From markus.icu at gmail.com Fri Jul 27 18:51:45 2007 From: markus.icu at gmail.com (Markus Scherer) Date: Fri, 27 Jul 2007 11:51:45 -0700 Subject: please update ICU homepage URL on http://www.twinsun.com/tz/tz-link.htm Message-ID: <6bb028490707271151g1f33a59k9a5d569d9e29fe26@mail.gmail.com> Dear TZ DB maintainers, Please update the ICU homepage URL on http://www.twinsun.com/tz/tz-link.htm from http://www-306.ibm.com/software/globalization/icu/ to http://icu-project.org/ Thanks and best regards, markus From yoshito_umaoka at us.ibm.com Fri Jul 27 19:00:49 2007 From: yoshito_umaoka at us.ibm.com (yoshito_umaoka at us.ibm.com) Date: Fri, 27 Jul 2007 15:00:49 -0400 Subject: FW: How to support such capabilites based on current Olson Time Zone implementation In-Reply-To: <6bb028490707271138x31eaae4es8d2cac06354bd4b6@mail.gmail.com> Message-ID: For the second requirement "getting the next nearest DST transition time", next version of ICU (ICU 3.8) will provide the API. -Yoshito "Markus Scherer" wrote on 07/27/2007 02:38:00 PM: > Dear Martin, > > For at least the first requirement, you might want to try other time > zone support libraries listed on this list's homepage [1], for example > ICU [2]. You could also send an email to the icu-support mailing list > [3] to see if your second can be provided for. > > [1] http://www.twinsun.com/tz/tz-link.htm > [2] http://icu-project.org/ > [3] http://icu-project.org/contacts.html > > Best regards, > markus From olsona at dc37a.nci.nih.gov Fri Jul 27 19:15:56 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Fri, 27 Jul 2007 15:15:56 -0400 Subject: FW: Does zic currently compile time zone abbreviations correctly? Message-ID: I'm forwarding this message from John Morrow, who is not on the time zone mailing list. Those of you who are on the time zone mailing list should direct replies appropriately. --ado -----Original Message----- From: John B. Morrow [mailto:jmorrow at sendwordnow.com] Sent: Friday, July 27, 2007 12:19 PM To: Olson, Arthur David (NIH/NCI) [E]; tz at lecserver.nci.nih.gov Subject: RE: Does zic currently compile time zone abbreviations correctly? This response and program was very helpful. Apparently I was missing the level of indirection that converted the type in the ttinfo into an abbrind to look up the abbreviation. For some time zones, that was fine and for others it wasn't. Now that I've added that additional level in, my program seems to be working correctly. Thank you for your quick response. John Morrow -----Original Message----- From: Olson, Arthur David (NIH/NCI) [E] [mailto:olsona at dc37a.nci.nih.gov] Sent: Friday, July 27, 2007 11:29 AM To: tz at elsie.nci.nih.gov Cc: John B. Morrow Subject: RE: Does zic currently compile time zone abbreviations correctly? The typescript below seems to indicate that there's nothing amiss with Europe/London; do you get different results if you run "tzhead"? --ado Script started on Fri 27 Jul 2007 11:24:37 AM EDT lecserver$ cat tzhead.c #include "private.h" struct tzhead { char tzh_magic[4]; /* TZ_MAGIC */ char tzh_version[1]; /* '\0' or '2' as of 2005 */ char tzh_reserved[15]; /* reserved--must be zero */ char tzh_ttisgmtcnt[4]; /* coded number of trans. time flags */ char tzh_ttisstdcnt[4]; /* coded number of trans. time flags */ char tzh_leapcnt[4]; /* coded number of leap seconds */ char tzh_timecnt[4]; /* coded number of transition times */ char tzh_typecnt[4]; /* coded number of local time types */ char tzh_charcnt[4]; /* coded number of abbr. chars */ }; static char * progname; static long long detzcode64(codep) const char * const codep; { register long long result; register int i; result = (codep[0] & 0x80) ? ~0L : 0L; for (i = 0; i < 8; ++i) result = result * 256 + (codep[i] & 0xff); return result; } static long long detzcode(codep) const char * const codep; { register long result; register int i; result = (codep[0] & 0x80) ? ~0L : 0L; for (i = 0; i < 4; ++i) result = (result << 8) | (codep[i] & 0xff); return result; } static void wild2exit(cp, dp) { (void) fprintf(stderr, "%s: wild result %s %s\n", progname, cp, dp); exit(1); } static void handle(filename) char * filename; { FILE * fp; struct tzhead tzh; long long ll; char c; int i; int pass; long ttisgmtcnt; long ttisstdcnt; long leapcnt; long timecnt; long typecnt; long charcnt; char buf[8]; struct tm tm; fp = fopen(filename, "r"); if (fp == NULL) wild2exit("result opening", filename); for (pass = 1; pass <= 2; ++pass) { if (fread(&tzh, sizeof tzh, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tversion\t", filename); c = tzh.tzh_version[0]; if (isascii(c) && isprint(c)) (void) putchar(c); else (void) printf("\\%o", c); (void) putchar('\n'); ttisgmtcnt = detzcode(tzh.tzh_ttisgmtcnt); ttisstdcnt = detzcode(tzh.tzh_ttisstdcnt); leapcnt = detzcode(tzh.tzh_leapcnt); timecnt = detzcode(tzh.tzh_timecnt); typecnt = detzcode(tzh.tzh_typecnt); charcnt = detzcode(tzh.tzh_charcnt); (void) printf("%s\tttisgmtcnt\t%ld\n", filename, ttisgmtcnt); (void) printf("%s\tttisstdcnt\t%ld\n", filename, ttisstdcnt); (void) printf("%s\tleapcnt\t%ld\n", filename, leapcnt); (void) printf("%s\ttimecnt\t%ld\n", filename, timecnt); (void) printf("%s\ttypecnt\t%ld\n", filename, typecnt); (void) printf("%s\tcharcnt\t%ld\n", filename, charcnt); for (i = 0; i < timecnt; ++i) { if (fread(buf, pass * 4, 1, fp) != 1) wild2exit("result reading", filename); ll = (pass == 1) ? detzcode(buf) : detzcode64(buf); { time_t l; l = ll; tm = *gmtime(&l); } (void) printf("%s\ttime[%d]\t%lld\t%s", filename, i, ll, asctime(&tm)); } for (i = 0; i < timecnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\ttype[%d]\t%d\n", filename, i, buf[0]); } for (i = 0; i < typecnt; ++i) { long l; if (fread(buf, 4, 1, fp) != 1) wild2exit("result reading", filename); l = detzcode(buf); (void) printf("%s\ttype[%d].offset\t%ld\n", filename, i, l); if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\ttype[%d].isdst\t%ld\n", filename, i, buf[0]); if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\ttype[%d].abbrind\t%ld\n", filename, i, buf[0]); } for (i = 0; i < charcnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tabbr[%d]\t", filename, i); if (isascii(buf[0]) && isprint(buf[0])) (void) printf("%c", buf[0]); else if (buf[0] == '\0') (void) printf("\\0"); else (void) printf("\%03o", buf[0]); (void) printf("\n"); } for (i = 0; i < ttisstdcnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tisstd[%d]\t%d\n", filename, i, buf[0]); } for (i = 0; i < ttisgmtcnt; ++i) { if (fread(buf, 1, 1, fp) != 1) wild2exit("result reading", filename); (void) printf("%s\tisgmt[%d]\t%d\n", filename, i, buf[0]); } if (tzh.tzh_version[0] != '2') break; } if (fclose(fp) != 0) { (void) fprintf(stderr, "%s: wild result closing %s\n", progname, filename); exit(1); } } int main(argc, argv) int argc; char * argv[]; { int i; progname = argv[0]; for (i = 1; i < argc; ++i) handle(argv[i]); exit(0); } lecserver$ make tzhead cc -DTZDIR=\"/usr/local/etc/zoneinfo\" tzhead.c -o tzhead lecserver$ tzhead tmp/etc/zoneinfo/Europe/London | grep abbr tmp/etc/zoneinfo/Europe/London type[0].abbrind 0 tmp/etc/zoneinfo/Europe/London type[1].abbrind 4 tmp/etc/zoneinfo/Europe/London type[2].abbrind 8 tmp/etc/zoneinfo/Europe/London type[3].abbrind 0 tmp/etc/zoneinfo/Europe/London type[4].abbrind 0 tmp/etc/zoneinfo/Europe/London type[5].abbrind 4 tmp/etc/zoneinfo/Europe/London type[6].abbrind 4 tmp/etc/zoneinfo/Europe/London abbr[0] B tmp/etc/zoneinfo/Europe/London abbr[1] S tmp/etc/zoneinfo/Europe/London abbr[2] T tmp/etc/zoneinfo/Europe/London abbr[3] \0 tmp/etc/zoneinfo/Europe/London abbr[4] G tmp/etc/zoneinfo/Europe/London abbr[5] M tmp/etc/zoneinfo/Europe/London abbr[6] T tmp/etc/zoneinfo/Europe/London abbr[7] \0 tmp/etc/zoneinfo/Europe/London abbr[8] B tmp/etc/zoneinfo/Europe/London abbr[9] D tmp/etc/zoneinfo/Europe/London abbr[10] S tmp/etc/zoneinfo/Europe/London abbr[11] T tmp/etc/zoneinfo/Europe/London abbr[12] \0 tmp/etc/zoneinfo/Europe/London type[0].abbrind 0 tmp/etc/zoneinfo/Europe/London type[1].abbrind 4 tmp/etc/zoneinfo/Europe/London type[2].abbrind 8 tmp/etc/zoneinfo/Europe/London type[3].abbrind 12 tmp/etc/zoneinfo/Europe/London type[4].abbrind 4 tmp/etc/zoneinfo/Europe/London type[5].abbrind 4 tmp/etc/zoneinfo/Europe/London type[6].abbrind 8 tmp/etc/zoneinfo/Europe/London type[7].abbrind 8 tmp/etc/zoneinfo/Europe/London abbr[0] L tmp/etc/zoneinfo/Europe/London abbr[1] M tmp/etc/zoneinfo/Europe/London abbr[2] T tmp/etc/zoneinfo/Europe/London abbr[3] \0 tmp/etc/zoneinfo/Europe/London abbr[4] B tmp/etc/zoneinfo/Europe/London abbr[5] S tmp/etc/zoneinfo/Europe/London abbr[6] T tmp/etc/zoneinfo/Europe/London abbr[7] \0 tmp/etc/zoneinfo/Europe/London abbr[8] G tmp/etc/zoneinfo/Europe/London abbr[9] M tmp/etc/zoneinfo/Europe/London abbr[10] T tmp/etc/zoneinfo/Europe/London abbr[11] \0 tmp/etc/zoneinfo/Europe/London abbr[12] B tmp/etc/zoneinfo/Europe/London abbr[13] D tmp/etc/zoneinfo/Europe/London abbr[14] S tmp/etc/zoneinfo/Europe/London abbr[15] T tmp/etc/zoneinfo/Europe/London abbr[16] \0 lecserver$ exit script done on Fri 27 Jul 2007 11:25:04 AM EDT From: John B. Morrow [mailto:jmorrow at sendwordnow.com] Sent: Friday, July 27, 2007 2:29 AM To: tz at lecserver.nci.nih.gov Subject: Does zic currently compile time zone abbreviations correctly? In the process of extracting time zone information from the zoneinfo database, I noticed that the abbreviation pointer break for quite a few time zones including Europe/London, Asia/Dubai, and quite a few others.? The problem seems to be in the compiled time zone files so I spent some time looking at zic.? What seems to be happening is that zic uses some criteria to determine of the abbreviation (and other info for types) is used and won't write it if it thinks it isn't needed.? The problem is that it doesn't adjust the indexes (tt_abbrind) that reference those abbreviations, so they'll point to bad data or empty strings.? My quick (and admittedly heavy handed fix) was to force zic to write all of the abbreviations, whether they are necessary or not.? If this really is a problem, it should probably be fixed at some point.? Please note that the data in our fairly recently updated Linux server has abbreviations that don't seem to work. If I'm missing something or there is some other way more correct way to reference the abbreviations, please let me know.? I'm using tt_abbrind as per the tzfile man page and the tzcode2007f.tar.gz sources. John Morrow From cppcraze at gmail.com Mon Jul 30 09:21:51 2007 From: cppcraze at gmail.com (Martin Dong) Date: Mon, 30 Jul 2007 17:21:51 +0800 Subject: FW: How to support such capabilites based on current Olson Time Zone implementation In-Reply-To: References: <6bb028490707271138x31eaae4es8d2cac06354bd4b6@mail.gmail.com> Message-ID: Dear Markus and Yoshito, Thanks for leading me to ICU project, which is really a full-featured library for internationalization. I feel it's more appropriate to consider using it from the very initial system design. However our system has already had its own internationalization mechanism, now we only want to utilize Olson Time Zone database. We need a light-weight solution but I think ICU is too heavy for us. Actually tzcode is a light-weight implementation, if I can make some change based on it to support what I want, I think it's enough. Dear Olson, I want to know more about tzfile in binary form. Is there any other detailed description? I feel it's a little bit hard to get it understood just through the tzcode (because the comments are vrey few:-). Btw, for now can any new functionality be added into tzcode implementation? Or another question, if my change can meet my requirements and it goes into our system, does it need to go into Olson tzcode? Sincerely, -Martin On 7/28/07, yoshito_umaoka at us.ibm.com wrote: > > For the second requirement "getting the next nearest DST transition time", > next version of ICU (ICU 3.8) will provide the API. > > -Yoshito > > "Markus Scherer" wrote on 07/27/2007 02:38:00 PM: > > > Dear Martin, > > > > For at least the first requirement, you might want to try other time > > zone support libraries listed on this list's homepage [1], for example > > ICU [2]. You could also send an email to the icu-support mailing list > > [3] to see if your second can be provided for. > > > > [1] http://www.twinsun.com/tz/tz-link.htm > > [2] http://icu-project.org/ > > [3] http://icu-project.org/contacts.html > > > > Best regards, > > markus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From olsona at dc37a.nci.nih.gov Mon Jul 30 13:29:03 2007 From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E]) Date: Mon, 30 Jul 2007 09:29:03 -0400 Subject: FW: How to support such capabilites based on current Olson Time Zone implementation Message-ID: I'm forwarding this message from Martin Doug, who is not on the time zone mailing list. Those of you who are on the time zone mailing list should direct replies appropriately. --ado From: Martin Dong [mailto:cppcraze at gmail.com] Sent: Monday, July 30, 2007 5:22 To: markus.icu at gmail.com; yoshito_umaoka at us.ibm.com Cc: tz at lecserver.nci.nih.gov Subject: Re: FW: How to support such capabilites based on current Olson Time Zone implementation Dear Markus and Yoshito, ? Thanks for leading me to ICU project, which is really a full-featured library for internationalization. I feel it's more appropriate to consider using it from the very?initial system design. However our system has already had its own internationalization mechanism, now we only want to utilize Olson Time Zone database.?We need a light-weight solution but I think ICU is too heavy for us. ? Actually tzcode is a light-weight implementation, if I can make some change based on it to support what I want, I think it's enough. ? Dear Olson, ? I want to know more about tzfile in binary form. Is there any other detailed description? I feel it's?a little bit hard to get it understood just through the tzcode (because the comments are vrey few:-). ? Btw,?for now can any new functionality be added into tzcode implementation? Or another question, if my change can meet my requirements and it goes into our system, does it need to go into Olson tzcode? ? Sincerely, -Martin ? On 7/28/07, yoshito_umaoka at us.ibm.com wrote: For the second requirement "getting the next nearest DST transition time", next version of ICU (ICU 3.8) will provide the API. -Yoshito "Markus Scherer" wrote on 07/27/2007 02:38:00 PM: > Dear Martin, > > For at least the first requirement, you might want to try other time > zone support libraries listed on this list's homepage [1], for example > ICU [2]. You could also send an email to the icu-support mailing list > [3] to see if your second can be provided for. > > [1] http://www.twinsun.com/tz/tz-link.htm > [2] http://icu-project.org/ > [3] http://icu-project.org/contacts.html > > Best regards, > markus