[tz] Converting cities to tz identifiers (tangent)

[John Hawkinson]

Paul.Koning at dell.com <Paul.Koning at dell.com> wrote on Tue, 20 Feb 2018
at 20:10:33 +0000 in <4FEED0AD-A1BA-4D23-B461-CB07F0F85045 at dell.com>:

> I would not recommend that.  "backward" exists, as the name suggests, only for backward compatibility with old naming conventions.

I'm not sure we've made such a statement of deprecation. I think a lot of people use the US/* style, even though it's not what the tz db prefers. I think a lot of people would be up-in-arms if those identifiers were deprecated anytime in foreseeable life of the project (measured in decades). But perhaps I am wrong (or too conservative).

> It may seem harder than necessary, but that may be because you haven't fully realized the depths of confusion that politicians will go to.

Nah, I'm well aware of it. But the fact of the matter is, in the United States, for non-historical timestamps, very few of the gotchas pop up. For sure, there are states that have multiple zones in them, but that's not (at least in my view) a "gotcha."

> Poking around Indiana will give you a good idea of why this stuff is
> harder than you might expect.  There you will find some per-county
> rules, and at some point in time county A might match county B while
> at another point in history it uses different rules.

See above. If we're dealing with present day (as I am), this is not a real concern.

> So yes, the answer really is as hard as it seems to be.

I think you mistake me.

> Well, US/x is just a link to America/y, for suitable y.  So there isn't any actual difference.

That's objectively false. The difference is what happens in the future when tz database breaks the link. 

> The real problem is this: If some of the places in an existing zone
> change their rules to differ from those of the rest of the zone, the
> new definition will have two zones where there used to be just one.

Correct. And that's why it matters what I choose. And that's also why
my inclination is to choose the US/* form.

> Consider a slightly stranger example [...]

It's because that's such an unlikely case that I'm not particularly worried about it. In my situation, I'm making a reasonable judgment between two choices that are unlikely to matter, but if they do, I'd like to choose the most maintainable and understandable choice that reduces future maintenance. Strange examples are good to be aware of, but aren't directly helpful.

> So to answer the question of the most stable identifier to use --
> there isn't one.

Oh, that's not true. There are lots of reasons to make choices about which identifier to use, and lots of ways to define stability. I offered some of my reasoning, and I'm curious what other people think (especially the argument for avoiding the "backward" zones, which I've always thought to be relatively weak arguments in the United States, but a lot stronger elsewhere).

> But that doesn't help predict what might happen next year, because
> you'd just be guessing what politicians might do and in general that
> isn't feasible.

False. Just because we cannot accurately predict the future does not mean we may not attempt it, and any choice in this space (America/New_York or US/Eastern) is such a prediction. We can't do it with perfect confidence, but certainly can do it, and arguably we must make such a choice. (Of course, we can make the choice by Rule instead of by evaluation of stability, and our Rule might be "Don't use the backward id's because *secret magic reason*." But it's still a choice.)

--jhawk at mit.edu
  John Hawkinson