On Feb 25, 2019, at 2:32 AM, Martin Burnicki <martin.burnicki@meinberg.de> wrote:
If the current time zone names should indeed just be taken as IDs rather than real names then IMO it would be very helpful if there also was a list of mappings provided that links readable display names to TZDB ID names.
Readable display names of what? I'm not sure what sort of name a tzdb region should have. tzdb regions can cross national boundaries, or can correspond to subregions of a nation or subdivision of a nation (such as a "state" in some English-speaking countries such as the US and Australia or as translated to English in some other countries such as Mexico, Germany, and Brazil, or a "province" in Canada). The tzdb project might have to *pick* a display name for some tzdb regions. and I suspect many involved with the project would *really* prefer that the project *not* do so - that would open it up to the same complaints some express about tzdb IDs now. And I'm not even convinced that users want to care about tzdb regions; those regions don't completely correspond to, for example, what people call "time zones" in the US, so "Mountain time" or "Mountain time zone" doesn't correspond to the America/Denver tzdb region - Arizona is in the "Mountain" time zone, but it hasn't done standard/summar time switching since 1968, unlike other parts of that time zone. What I suspect users want is to have clock time work appropriately for their location; if doing so doesn't involve knowing or caring about the details of the tzdb, so much the better. And, in fact, that works pretty well on my Mac and iPhone. They're currently set up to use their mechanisms to determine the current longitude and latitude of the machine ("Core Location", which can use GPS on iPhones that have it, and can use other mechanisms such as known locations of mobile telephony cells and Wi-Fi access points on machines lacking GPS) to pick the tzdb region; if that's disabled, then, at least on the Mac, I can pick a location on a map, or type the name of a city into a text box, to select the tzdb region. The city does *NOT* have to be the city used in the tzdb region's name. And when I say "current longitude and latitude of the machine", I mean that if its location changes, the current time zone changes. When I traveled from California to Pennsylvania a few years ago, the time zone switched, and it switched back when I returned. *That* required not only Core Location, to determine my location, but also required a mechanism to deliver notifications to *all* processes (not just processes running written-for-macOS GUI programs, but UN*X programs that just use localtime() or time()) that the time zone has changed. That's buried in the C library, so that if you run this program: #include <stdio.h> #include <time.h> #include <unistd.h> int main(void) { for (;;) { time_t now; now = time(NULL); printf("%s", ctime(&now)); sleep(600); } } it will, if you move from one time zone to another, switch from the old time zone to the new time zone when displaying the time.
Otherwise each project has to do this by itself, and the problem seems to be that some projects just use the ID names from TZDB while other projects do the mapping by themselves.
If there was a mapping list included with TZDB then different projects could rely to them and use the same, consistent information and displaying.
If there was a generally-available mapping mechanism, whether it's included with the tzdb or not, then different projects could rely on it and use the same, consistent information and displaying. And it appears there is such a mechanism. The GeoNames project: https://www.geonames.org records information about a lot of locations, *including* tzdb ID information. They offer a number of Web services: https://www.geonames.org/export/web-services.html including one to look up the tzdb region (and some other information) for a given longitude and latitude: http://www.geonames.org/export/web-services.html#timezone It has other services to look up cities, getting the longitude and latitude and, I think, to find cities within a given area. They list on their About page: https://www.geonames.org/about.html both "Apple Snowleopard" and Ubuntu as uses of the data base; I don't know whether macOS or iOS use it for their tzdb region selection, but Ubuntu have their own Web service used in *its* time zone selector UI: https://launchpad.net/ubuntu-geonames which I think uses the GeoNames database, periodically downloading it and generating their own database (so as not to burden the GeoNames service).
Anyway, there's still a different point. I'm assuming that English is the native language for most members of this list, but most applications taking care about time zones let users select them zone in their native language, so some internationalization would also be very helpful.
For example, the zone "Europe/Macedonia" is displayed as "Europa/Makedonien" on my Linux/KDE system set to German language.
"Europe/Macedonia" is not a tzdb ID and, as far s I know, never has been. The ID for the tzdb region that includes North Macedonia is Europe/Belgrade; for historical reasons, there is a historical link from Europe/Skopje to Europe/Belgrade. Therefore, it's not as if the tzdb hasn't internationalized something here - the tzdb didn't supply Europe/Macedonia in the first place, some other entity did, and you should ask *them* to internationalize it - or ask them to use the CLDR: http://cldr.unicode.org