[tz] tzdb timezone names/identifiers and links

Fred Gleason fredg at paravelsystems.com
Tue Feb 26 22:22:26 UTC 2019

On Tue, 2019-02-26 at 14:03 -0800, Guy Harris wrote:
> Actually, that's not a question of "pushing complexity away from the
> programmers", it's a question of "users who don't need to know the
> details, and whose heads would probably explode if forced to deal
> with the details" vs. "users who need, for technical reasons, to deal
> with the details".

Yes, that's a better way to put it.

> People who deal with those issues and therefore have to know about
> tzdb regions should be clueful enough to know that the tzdb IDs are
> chosen not as user-friendly names and, therefore, that "but I'm in
> City X, not City Y!" is a complaint that should and will receive
> little sympathy here, as the Theory file states the rules we use to
> select the city, and "that's not how we pronounce the city's name" is
> a complaint to be addressed by getting the English-speaking community
> to change the name they use for the city (cf. Bombay -> Mumbai).
> So, for that subset of professional engineers who have to know about
> not just time zones and summer time in general, but about tzdb
> regions in particular, you can use tzdb IDs.

Yup. It's a numerically small group I know, but is the one I primarily
serve. Don't forget about us!  :)

> If there are are engineers who have to know about tzdb regions, but
> aren't yet familiar with the tzdb, the documentation for whatever
> product is being discussed should explain it to them - including the
> rules from the Theory file, so they understand that the names don't
> necessarily correspond to, and aren't intended to correspond to, the
> layman's notion of the name for a "time zone", or "the most important
> city in z time zone, for some definition of "most important"", or
> anything such as that.

Basically, just provide a link to the Theory file.


| Frederick F. Gleason, Jr. |             Chief Developer             |
|                           |             Paravel Systems             |
|   There are two ways of constructing a software design. One is to   |
|   make it so simple that there are obviously no deficiencies; the   |
|   other is to make it so complicated that there are no obvious      |
|   deficiencies. The first method is far more difficult.             |
|                                                                     |
|                                                    -- C.A.R Hoare   |

More information about the tz mailing list