<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 12/4/17 23:02, Tim Parenti wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAFpi07wb3D5uwdWSV_VkB1Zdjuffm+6y4YtPGZMo4gHUM7E2mA@mail.gmail.com">
<div dir="ltr">On 4 December 2017 at 19:21, Michael Douglass <span
dir="ltr"><<a href="mailto:mikeadouglass@gmail.com"
target="_blank" moz-do-not-send="true">mikeadouglass@gmail.<wbr>com</a>></span> wrote:
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.</blockquote>
<div><br>
</div>
<div>On 4 December 2017 at 19:38, David Patte ₯ <span dir="ltr"><<a
href="mailto:dpatte@relativedata.com" target="_blank"
moz-do-not-send="true">dpatte@relativedata.com</a>></span> wr<wbr>ote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">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.</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</blockquote>
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.<br>
<blockquote type="cite"
cite="mid:CAFpi07wb3D5uwdWSV_VkB1Zdjuffm+6y4YtPGZMo4gHUM7E2mA@mail.gmail.com">
<div dir="ltr">
<div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"><span
style="font-size:12.8px">But what about the tz
designations (such as EDT), do we have a solution to that
conundrum?</span></blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</blockquote>
<blockquote type="cite"
cite="mid:CAFpi07wb3D5uwdWSV_VkB1Zdjuffm+6y4YtPGZMo4gHUM7E2mA@mail.gmail.com">
<div dir="ltr">
<div>
<div class="gmail_extra"><br clear="all">
<div>
<div
class="gmail-m_6366588128611744569m_-4262253798557522349gmail_signature">--<br>
Tim Parenti</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>