[tz] Please include Montreal
guy at alum.mit.edu
Mon Nov 13 18:23:55 UTC 2017
On Nov 13, 2017, at 9:29 AM, Paul G <paul at ganssle.io> wrote:
> Well, I was just trying to clarify what it seemed like Guy was saying. If you're using tzdb names and aliases as a list of cities where the time zone applies, your UI is more or less broken, since tzdb uses a specific, historically-contingent subset of those cities and other aliases as the names of the zones.
> What I will say is that while it's probably not going to kill your application if you do this, it's definitely not great UI. I remember before I knew anything about time zones or tzdb I would set up computers and find that if I wanted central time, I could only set up America/Chicago - what were the implications of that if I was in Houston? Why wasn't Houston on the map? How do I even know that Chicago is on Central time? Same for anyone in San Francisco whose only choice is Los Angeles.
> You're basically exposing an implementation detail of the database (the primary key which happens to be human-readable) in your UI, which is a lazy and confusing design. Not to mention it doesn't come with localization. If you want to say, "Here's a crude UI that lets you select tzdb keys, which are often named after cities", that's fine, but if you want a good user experience (even for people with no political agenda), you should probably design something where the workflow is more like "Tell me where you are (some way to select this - possibly a list of all major cities) and I'll set your time zone appropriately (or give you options if you're in some weird edge case where it may be uncertain which time zone rules you're using)."
> This has been fleshed out in many threads on this mailing list in the past, I don't think it's particularly controversial to say that "the key names should be user-friendly" is not within the scope of this project.
Yes. That's *exactly* my point.
More information about the tz