[tz] Reason for removal of several TZ abbreviations
Tim Parenti
tim at timtimeonline.com
Tue Dec 5 04:02:39 UTC 2017
On 4 December 2017 at 19:21, Michael Douglass <mikeadouglass at gmail.com>
wrote:
>
> Then we can stop having these long arguments about why one name or another
> isn't in the tz data. Everybody is free to generate their own list if they
> so wish.
On 4 December 2017 at 19:38, David Patte ₯ <dpatte at relativedata.com> wrote:
> Using such a scheme, a database such as geonames would then map a location
> to the tz id (as it does now), defering political arguments to geonames,
> and removing them from this list. It seems appropriate.
Except it likely doesn't make anything better for maintenance. With
strictly opaque IDs, this project would still need to track the approximate
geographical scope of each identifier in much the same manner as we already
do, so as to aid in identifying when zone splits are necessary, etc.
Currently, that task is fairly clear with human-readable IDs identifying a
city and commentary filling in the details where necessary. This is, of
course, only done to roughly record the general contours of zones so we
know how to update them, not any attempt at recording precise borders.
Indeed, it is (or should be) well-known to this list that our IDs can be
considered to overlap geographically in several cases, and that these are
often the most geopolitically divisive cases.
Replacing IDs with opaque strings would complicate this maintenance
somewhat, although that complication could be mitigated by further
standardization our geographical commentary to assist in maintenance.
However, at that point, the questions don't become "why doesn't Important
City have its own ID?" but rather "why isn't Important City in the
commentary for this ID?" or "why is Important City listed in the commentary
for the 'wrong' ID?" And so, just like now, we'd continue recording the
existence of disputes and the like with care, while not taking any stance
and pushing back on requests to conform to any particular side. So
ultimately, we'd get different questions, sure… but I'm entirely
unconvinced they'd be any fewer or any less political.
Frankly, I've long thought the whole idea of fully-opaque IDs is a
non-starter, and I'd much rather see our collective efforts spent
elsewhere. Time zones are inherently geopolitical in nature; we can
certainly work to minimize the impact of geopolitics on this project, but
we cannot eliminate it entirely, and efforts to do so are fruitless.
But what about the tz designations (such as EDT), do we have a solution to
> that conundrum?
In the past, there was a proposal to simply eliminate them all, and use
some static string like "zzz", "-", "local", or "". But this has similar
problems as above, since it is impossible to identify the source zone or
corresponding UTC timepoint. The numeric %z format that many zones have
recently moved to is marginally better in the one regard, but we've seen
that that has had (the expected) knock-on effects caused by (mis)use of the
"abbreviation" field when heuristics fail to identify the correct source
zone from the incomplete information.
Honestly, if it weren't for character limitations, the "abbreviation" field
should probably just return something akin to "<-05>America/New_York" for
all zones at all times, leaving strings like "EST" (in English) or "HNE"
(in French) to localization projects like CLDR. This would have the
advantage of providing everything needed to reconstruct the UTC timepoint
and identify the source zone (given a specific version of this project, at
least), but the distinct disadvantage of being a bit unwieldy.
--
Tim Parenti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20171204/efeee7bb/attachment.htm>
More information about the tz
mailing list