[tz] Please include Montreal

Paul G paul at ganssle.io
Mon Nov 13 17:29:46 UTC 2017

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.

On 11/13/2017 12:01 PM, Robert Elz wrote:
>     Date:        Mon, 13 Nov 2017 14:20:08 +0000
>     From:        Paul G <paul at ganssle.io>
>     Message-ID:  <8BDF3C45-0FD2-4D54-939B-F4B20E5DE70D at ganssle.io>
>   | I'm pretty sure that's what Guy is saying. If you define your UI based on
>   | tzdb zone names, your UI is broken.
> Not broken, just less than optimal for some user classes.   Like the
> type that want city XXX listed, because "that's our capital" or because
> "that lot don't speak French" or ...
> For example, the NetBSD UI for changing the timezone, or setting it
> after initial installation (if it wasn't done then) is:
> 	ln -sf /usr/share/zoneinfo/xxx/yyy /etc/localtime
> or
> 	echo export TZ=xxx/yyy >> .profile
> or similar (depending upon what kind of change is being made.)
> Discovering what to use for xxx/yyy is left to the user (tzselect is
> not installed.)
> That works just fine, and is entirely suitable for the kinds of users
> NetBSD tends to attract.
> kre
> ps: there is a menu based approach available during system installation
> to make this a little easier for first time users.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mm.icann.org/pipermail/tz/attachments/20171113/60f8ed16/signature.asc>

More information about the tz mailing list