[tz] Comments and mapping of tz zones to the real world
tobias.conradi at gmail.com
Wed May 9 02:17:25 UTC 2012
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:
>> Can you tell a way of how a user determines the correct zone for a
>> random location in Indiana, selecting between
>> 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.
America/Indiana/Vincennes is the zone for counties Daviess, Dubois, Knox, Martin
Vincennes is the seat for
Not bordering Knox is
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
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.
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
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
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.
Rheinsberger Str. 18
More information about the tz