[tz] Reason for removal of several TZ abbreviations
mikeadouglass at gmail.com
Tue Dec 5 04:16:43 UTC 2017
On 12/4/17 23:02, Tim Parenti wrote:
> On 4 December 2017 at 19:21, Michael Douglass <mikeadouglass at gmail.com
> <mailto: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
> <mailto: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
> 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
> 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.
The names unfortunately are political - like it or not. Apparently there
are organizations that cannot use this data for that reason. Using the
current naming as an internal reference is fine but the timezones
themselves should have an opaque id that doesn't cause problems. CLDR
provides localization data - we just need a new key. You can be (almost)
apolitical when all you do is record the use of time in certain
geographic regions. You can't be when you assign disputed names to them.
People will assign motive to your actions whatever your intentions.
> 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...
More information about the tz