On May 8, 2012, at 7:17 PM, Tobias Conradi wrote:
On Wed, May 9, 2012 at 12:45 AM, Guy Harris <guy@alum.mit.edu> wrote:
On May 5, 2012, at 11:03 PM, Tobias Conradi wrote:
Clever computer if it can determine the county where one is located.
It can, and did, determine the *city* where I'm located: http://support.apple.com/kb/HT4239 "Location Services allow applications to use information from Wi-Fi networks to determine your approximate location. In order to use Location Services, you must have an AirPort connection that can scan for nearby networks, and also a connection to the Internet."
In case one is temporarily located in another county than the one, one wishes to set the zone for, this method can fail.
Yes, in which case you'd un-check the "Set time zone automatically using current location" check box and set it manually. On the other hand, if one is temporarily located in a county that *is* the one for you wish to, at this time, set the zone, then this method wins. (That was the case, for example, when I was in Pennsylvania in late March. That was the point at which I turned on "Set time zone automatically using current location".)
2) dragging the blue "current time zone" stripe to "Eastern Standard Time" if it's not already there, or clicking on the map near Indiana, and selecting the appropriate entry from the "Closest City" drop-down list.
As of 2012 there are several tz zones that yield Eastern Standard Time.
Sorry, I wasn't clear enough. The stripe in question is on the map (see the screenshot in the URL I list up there), so it corresponds to a geographical region, not to a "time zone" such as the US Eastern time zone.
In tzdata2012c/zone.tab there are the following ten:
America/New_York Eastern Time America/Detroit Eastern Time - Michigan - most locations America/Kentucky/Louisville Eastern Time - Kentucky - Louisville area America/Kentucky/Monticello Eastern Time - Kentucky - Wayne County America/Indiana/Indianapolis Eastern Time - Indiana - most locations America/Indiana/Vincennes Eastern Time - Indiana - Daviess, Dubois, Knox & Martin Counties America/Indiana/Winamac Eastern Time - Indiana - Pulaski County America/Indiana/Marengo Eastern Time - Indiana - Crawford County America/Indiana/Petersburg Eastern Time - Indiana - Pike County America/Indiana/Vevay Eastern Time - Indiana - Switzerland County
One may want the zone for location A, but the "Closest City" drop-down may not include location A. The closest city may be across the border in a county that is located in another tz zone. Then one does not get the tz zone for location A.
If I set the "current time zone" stripe to the one that reports "Eastern Standard Time", the Snow Leopard version of the System Preferences Date & Time pane offers only Fort Wayne and Indianapolis as "Closest City". I don't know whether this is because its list of "Closest Cities" is based on an older version of the CLDR or not based on the CLDR at all (paging Deborah Goldsmith...); the 2.1 version of the CLDR: http://unicode.org/Public/cldr/21/core.zip has, in bcp47/timezone.xml: tz database names City America/Indiana/Marengo Marengo (Indiana), United States America/Indianapolis America/Fort_Wayne America/Indiana/Indianapolis US/East-Indiana Indianapolis, United States America/Indiana/Vevay Vevay (Indiana), United States America/Indiana/Knox America/Knox_IN US/Indiana-Starke Knox (Indiana), United States America/Indiana/Vincennes Vincennes (Indiana), United States America/Indiana/Tell_City Tell City (Indiana), United States America/Indiana/Winamac Winamac (Indiana), United States America/Indiana/Petersburg Petersburg (Indiana), United States for Indiana. Yes, the "closest city" might be in a different state. The underlying problem there is "what user-friendly way is there to specify a tz database zone name to the user, so that they don't have to know obscure information that requires them to read the source files for the tz database?" Closest city? County name? Something else?
I.e., the *user*, in the sense of "the end user", shouldn't have to even know about the time zone names; there should be a layer of software doing a better job of letting the user select the zone (or selecting it for them). The Theory file says:
This naming convention is not intended for use by inexperienced users to select TZ values by themselves
Depending on how "inexperienced users" is defined, even experienced users may not be able to determine the correct zone by only looking at the zone names. I think the Theory file is misleading, buggy here.
The Theory file only implicitly, at best, says that the naming convention *should be* sufficient for "experienced" users in all cases; it's just saying that the goal is not to make it sufficient for users with arbitrary little experience to use just the names to select a zone (i.e., that the names are not chosen primarily to suggest to inexperienced users what zone is appropriate, just as the conventions for the LANG environment variable are not designed to make it possible for somebody unaware of ISO 3166, ISO 639, and whatever scheme is used to label character encodings to determine the correct LANG setting.
Distributors should provide documentation and/or a simple selection interface that explains the names; see the 'tzselect' program supplied with this distribution for one example.
tzcode2012b/tzselect.8.txt says: FILES TZDIR/zone.tab Table of country codes, latitude and longitude, TZ values, and descriptive comments.
That may mean the end user has to rely on the comments column of zone.tab.
Well, yes, in the sense that what tzselect prints comes from that column: $ cd tzdata2012c/ $ sh ../tzcode2012b/tzselect.ksh Please identify a location so that time zone rules can be set correctly. Please select a continent or ocean. 1) Africa 2) Americas 3) Antarctica 4) Arctic Ocean 5) Asia 6) Atlantic Ocean 7) Australia 8) Europe 9) Indian Ocean 10) Pacific Ocean 11) none - I want to specify the time zone using the Posix TZ format. #? Americas Please enter a number in range. #? 2 Please select a country. 1) Anguilla 28) Haiti 2) Antigua & Barbuda 29) Honduras 3) Argentina 30) Jamaica 4) Aruba 31) Martinique 5) Bahamas 32) Mexico 6) Barbados 33) Montserrat 7) Belize 34) Nicaragua 8) Bolivia 35) Panama 9) Bonaire Sint Eustatius & Saba 36) Paraguay 10) Brazil 37) Peru 11) Canada 38) Puerto Rico 12) Cayman Islands 39) Sint Maarten 13) Chile 40) St Barthelemy 14) Colombia 41) St Kitts & Nevis 15) Costa Rica 42) St Lucia 16) Cuba 43) St Martin (French part) 17) Curacao 44) St Pierre & Miquelon 18) Dominica 45) St Vincent 19) Dominican Republic 46) Suriname 20) Ecuador 47) Trinidad & Tobago 21) El Salvador 48) Turks & Caicos Is 22) French Guiana 49) United States 23) Greenland 50) Uruguay 24) Grenada 51) Venezuela 25) Guadeloupe 52) Virgin Islands (UK) 26) Guatemala 53) Virgin Islands (US) 27) Guyana #? 49 Please select one of the following time zone regions. 1) Eastern Time 2) Eastern Time - Michigan - most locations 3) Eastern Time - Kentucky - Louisville area 4) Eastern Time - Kentucky - Wayne County 5) Eastern Time - Indiana - most locations 6) Eastern Time - Indiana - Daviess, Dubois, Knox & Martin Counties 7) Eastern Time - Indiana - Pulaski County 8) Eastern Time - Indiana - Crawford County 9) Eastern Time - Indiana - Pike County 10) Eastern Time - Indiana - Switzerland County 11) Central Time 12) Central Time - Indiana - Perry County 13) Central Time - Indiana - Starke County 14) Central Time - Michigan - Dickinson, Gogebic, Iron & Menominee Counties 15) Central Time - North Dakota - Oliver County 16) Central Time - North Dakota - Morton County (except Mandan area) 17) Central Time - North Dakota - Mercer County 18) Mountain Time 19) Mountain Time - south Idaho & east Oregon 20) Mountain Time - Navajo 21) Mountain Standard Time - Arizona 22) Pacific Time 23) Alaska Time 24) Alaska Time - Alaska panhandle 25) Alaska Time - southeast Alaska panhandle 26) Alaska Time - Alaska panhandle neck 27) Alaska Time - west Alaska 28) Aleutian Islands 29) Metlakatla Time - Annette Island 30) Hawaii ... (the strings in the last list come from the "comments" field in zone.tab).
tzcode2012b/tzselect.8.txt doesn't indicate any mapping apart from that provided by the tzdb, i.e. the authors of the software didn't figure out any mapping (=create own mapping). And the DB that tzselect uses is the tzdb.
Well, if "the tzdb" includes "zone.tab", yes. If it only means the files produced by zic, no - as the man page indicates, it reads both iso3166.tab and zone.tab, in addition to the time zone data files.
The comments aren't "part of the database" in the sense that zic reads them and produces a file based on what they say.
Then zic uses only part of the database.
If by that you mean "it ignores the comments in the source files", yes - they are, after all, comments, in the "comments in a source file" sense (rather than in the sense in which "comments" is used in zone.tab), and they're ignored by the zone info compiler (zic), just as the C compiler would ignore the comment in x += 2; /* multiply x by 43 and take its cosine */
I would use one software to determine the extend of the database. E.g. there is another software, tzselect, which according to tzcode2012b/tzselect.8.txt seems to use the comments column from the zone.tab.
Yes, it does use that. Perhaps that column should be called "description" rather than "comments", so that it's not confused with "comments" in the sense of # Lines beginning with `#' are comments. in zone.tab. That description is, however, in English: CN +4348+08735 Asia/Urumqi most of Tibet & Xinjiang so it's probably not sufficient for a "general users" user interface.
They could, however, perhaps be viewed as "part of the database" in the sense that they are documentation for the database, in which case an error in a comment would be a documentation bug for the database.
Agreed. That would not only include the comment column in the zone.tab, but also the comments in the region(?) files, e.g. in the "europe" file.
Well, the latter comments are "comments" in the "comments in a source file" sense, and thus only read and understood by humans - software reads it but discards it. They'd be useful for humans constructing other databases, such as the CLDR, from the tz database source files, but not useful for software.
But for Russia (map at http://efele.net/maps/tz/russia/ ) the zone.tab data is not sufficient for the zones: Europe/Moscow Moscow+00 - west Russia Europe/Volgograd Moscow+00 - Caspian Sea Europe/Samara Moscow+00 - Samara, Udmurtia
The comments in the europe file give for Europe/Volgograd # Astrakhanskaya oblast', Kirovskaya oblast', Saratovskaya oblast', # Volgogradskaya oblast'.
Without that information mapping may fail. This information is needed.
So perhaps either 1) zone.tab needs to have something better than "Moscow+00 - {xxx}" in it or 2) zone.tab needs more fields or perhaps whatever *localized* databases are used by various OS's/desktop environments' time zone selection UIs needs to have more information.
Theory file says ============= ----- Scope of the tz database -----
The tz database attempts to record the history and predicted future of all computer-based clocks that track civil time. To represent this data, the world is partitioned into regions whose clocks all agree about time stamps that occur after the somewhat-arbitrary cutoff point of the POSIX Epoch (1970-01-01 00:00:00 UTC). ==============
If one puts Saratov Oblast into Europe/Moscow in the comments, while Saratov Oblast after the cutoff point observed the transitions as given in Europe/Volgograd, there would be a violation of sentence two of the scope section "...regions whose clocks all agree..."
Yes, that would be a bug in the database documentation, i.e. in the comments. Now, the non-comment portions of the zic source files enumerate all the regions - every line that begins with "Zone" gives a region. That does give a list of regions, but the non-comment portions don't "partition the world" in the sense that they indicate which particular parts of the world belong to particular regions; in effect, that's left up to the comments and the zone.tab file. Given that the non-comment portions of the zic source files don't actually indicate what parts of the world belong to particular zones, the non-comment portions of the zic source files don't provide enough information to indicate whether any of the regions in question have all clocks within that region agreeing post-Epoch, as they don't provide enough information to indicate what clocks are or aren't in that region....