[tz] Comments and mapping of tz zones to the real world
Guy Harris
guy at alum.mit.edu
Wed May 9 07:55:54 UTC 2012
On May 8, 2012, at 7:17 PM, Tobias Conradi wrote:
> On Wed, May 9, 2012 at 12:45 AM, Guy Harris <guy at 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....
More information about the tz
mailing list