[tz] tzdb timezone names/identifiers and links

[Fred Gleason]

On Tue, 2019-02-26 at 12:14 -0800, Guy Harris wrote:
> Is an ethnic Han living there less likely to realize that "China" is
> more appropriate than "Xinjiang" or "Urumqi" for them than they are
> to realize that "Asia/Shanghai" is more appropriate than
> "Asia/Urumqi"?  If so, why?

I suspect that there would be a fair amount of experimentation in
either case, until the user found the 'correct' setting --i.e. the one
that made his clock match that of the people around him with which he
interacts.


> So presumably the tradeoff here is implementation complexity that the
> programmer's brain has to deal with vs. UI complexity that the end
> user's brain has to deal with, with the indirection taking away UI
> complexity for the end user (i.e., having to understand about the
> notion of tzdb regions and their IDs).

Exactly correct, which is why the intended audience must be taken into
account when considering these tradeoffs. If that audience is "Aunt
Millie on her cellphone", then I quite agree that presenting raw tzdb
IDs is not the optimum UI choice. OTOH, if that audience consists of
(say) professional engineers who deal with these sorts of issues
routinely, then yes, they want the tzdb IDs, not some interpreted
version of what I think they 'really' meant.

Perhaps a real-life example would help. I used to do a fair amount of
work with the Internet Domain Name System (DNS). That community has
evolved a set of specific, very precise terms for describing various
DNS attributes, such as 'host', 'zone', and 'record'. The problem
domain is somewhat complex, and precision is important to understanding
and communicating what it is that one is trying to accomplish. However,
certain domain name registrars (names omitted here to protect the
guilty) have seen fit to completely eschew the use of these terms in
their management UIs (doubtless because they would be 'too
intimidating' for Aunt Millie to deal with when setting up her web site
for selling her home baked cupcakes). The result is to make them nearly
incomprehensible to a person who *does* understand the problem domain.
For example, what does changing 'the location to which the domain
points' actually *mean*? A change to the 'A' record of the top level
domain, or to the 'www' host? Or both? Or something else? How about if
you have multiple hosts assigned to the domain, not just 'your web
site'? And so on...

I don't disagree with providing appropriate interfaces for non-
technical users where that's necessary. I do however disagree with
sweeping statements to the effect that such 'interpreted' views are the
*only* acceptable forms in which tzdb data may be displayed. In
particular, I disagree with certain proposals I've seen here, such as
to replace the existing location identifiers with opaque alpha-numeric
strings. That strikes me as adding pointless complexity, merely for the
sake of forcing UI designers to add that extra layer of indirection
through some other registry (which will, inevitably, then have to deal
with all of the arguments about names/spelling/orthographies/etc that
we see here on a regular basis).

Civil time (like most things having to do with human culture) is
inherently messy and idiocyncratic. Let's not make it even more complex
than it needs to be.

Cheers!


|---------------------------------------------------------------------|
| Frederick F. Gleason, Jr. |             Chief Developer             |
|                           |             Paravel Systems             |
|---------------------------------------------------------------------|
|   When you feel the urge to design a complex binary file format,    |
|   it's generally wise to lie down until the feeling passes.         |
|                                                                     |
|                                     -- Eric Raymond                 |
|                                     "The Art of UNIX Programming"   |
|---------------------------------------------------------------------|