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:
Can you tell a way of how a user determines the correct zone for a random location in Indiana, selecting between
America/Indiana/Indianapolis America/Indiana/Vincennes America/Indiana/Winamac America/Indiana/Marengo America/Indiana/Petersburg America/Indiana/Vevay America/Kentucky/Louisville America/New York
without reading the comments?
Well, on the machine on which I'm typing this, they do so by launching System Preferences, clicking on "Date & Time", and either:
1) checking the "Set time zone automatically using current location" check box and letting the computer do the work of figuring out where you are and what zone would be appropriate
Clever computer if it can determine the county where one is located. In case one is temporarily located in another county than the one, one wishes to set the zone for, this method can fail.
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. 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.
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.
e.g. America/Indiana/Vincennes is the zone for counties Daviess, Dubois, Knox, Martin Vincennes is the seat for http://en.wikipedia.org/wiki/Knox_County,_Indiana Not bordering Knox is http://en.wikipedia.org/wiki/Dubois_County,_Indiana Instead Dubois has borders to Pike County with seat Petersburg which is the reference point for America/Indiana/Petersburg and Crawford County with largest town Marengo, the reference point for America/Indiana/Marengo. I think that without the explicit statement in zone.tab or with comments in the northamerica file, one could not determine from the tzdb that Dubois is located in America/Indiana/Vincennes.
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.
However, that then means that the authors of the software, and the maintainers of whatever databases it uses, would need to figure out the right zones for particular locations, and the comments might help there.
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.
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. 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.
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.
For the US, the comment column in the zone.tab may be sufficient. 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. And if these comments put a location in the wrong timezone, than the mapping fails to. It would be a bug. That's what Tobias Conradi claimed at http://mm.icann.org/pipermail/tz/2012-May/017691.html Q: So, what is the effect if we put it into the wrong timezone? A: The database would contain a bug according to tzcode2011i/Theory: And what at least one user contested. 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..." If such placement of Saratov Oblast is not a bug, then the Theory file contains a bug in the scope section. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/