Re: [tz] Timezone error (Kyiv not Kiev)
Steve Summit wrote:
What end-user interfaces are there that present raw tz identifiers for selection, and that might therefore confuse or offend users if the spellings are culturally inappropriate?
I’ve seen them shown (and have used them myself 'as-is') in multiple astronomy apps. (I double checked some apps today, and they are there.) I’ve never quite understood the "don’t show them to the user" argument. When I first became involved in using time zone data in a desktop application some years ago (via geonames and other downstream tzdata repackaging projects), from memory there was no mention of this guidance. It would be wrong to assume downstream consumers even know about it. And given that TZ IDs conspicuously pass the "duck test” it’s hardly surprising to see them making public appearances. They appear perfectly suited to show in a UI (with underscores replaced by spaces, I suppose). That said, replacing them with an anonymous identifier (e.g. 7252) would be a major negative for usability of the data (at least from a development/testing perspective). And while it would kick the problem downstream, it’s not going to eliminate it. I imagine many of the new set of downstream TZ ID-to-human readable translation errors or disputes that would undoubtedly ensue would land back on this list anyway.
As regulars well know, but newcomers may not, time zone identifiers are just that: identifiers.
True, but clearly there’s major inertia when it comes to changing them, as evidenced by the last several years of debate on K**v. So which is it? Easily mutable identifiers that users supposedly never see or human consumable ‘readable’ IDs?
On Jul 5, 2022, at 3:09 PM, Stephen Trainor (Crookneck) via tz <tz@iana.org> wrote:
And given that TZ IDs conspicuously pass the "duck test” it’s hardly surprising to see them making public appearances. They appear perfectly suited to show in a UI
I don't live in Los Angeles. A UI that offers me only a choice of "Los Angeles" is inferior to one that allows me to specify where I live - which is *not* a location that would need its own tzdb region. And the UIs on my laptop and on my phone allow me to specify my location using the name of the city where I live. (They're not perfect, as they don't acknowledge the existence of Weed, CA, at least as of the OS release running on them.) (Then again, what I have on both of them are OSes with code that keeps track of where the machine is located and, based on that, automatically determines the appropriate tzdb region and, if the appropriate region doesn't match the current setting, changes the current setting. And, yes, it changes it out from under running programs. And, yes, that includes programs using APIs such as localtime() and mtkime(). And, yes, the OS on the laptop, at least, is a Single-UNIX-Specification-certified Unix.)
I don’t disagree with any of that. However, there are plenty of use cases where you care about the time zone: - in a place other than your device's current location - where your planned location doesn’t have a good name (e.g. a wilderness area) - and want to be certain which rules are being applied (e.g. Page, AZ and surrounding area), i.e. call it whatever hyperlocal name you want, but I still need to know which TZ rules you're applying (and the TZID is the best proxy, as opposed to trying to read the actual rules). Inferior, i.e. a finite set of TZ IDs being available to the user in a UI, does not mean without value. The standard OS UIs don’t typically accommodate the ‘remote planning’ scenarios mentioned above so well (or at all - they’re typically application specific).
On Jul 5, 2022, at 16:32, Guy Harris <gharris@sonic.net> wrote:
On Jul 5, 2022, at 3:09 PM, Stephen Trainor (Crookneck) via tz <tz@iana.org> wrote:
And given that TZ IDs conspicuously pass the "duck test” it’s hardly surprising to see them making public appearances. They appear perfectly suited to show in a UI
I don't live in Los Angeles. A UI that offers me only a choice of "Los Angeles" is inferior to one that allows me to specify where I live - which is *not* a location that would need its own tzdb region.
And the UIs on my laptop and on my phone allow me to specify my location using the name of the city where I live. (They're not perfect, as they don't acknowledge the existence of Weed, CA, at least as of the OS release running on them.)
(Then again, what I have on both of them are OSes with code that keeps track of where the machine is located and, based on that, automatically determines the appropriate tzdb region and, if the appropriate region doesn't match the current setting, changes the current setting. And, yes, it changes it out from under running programs. And, yes, that includes programs using APIs such as localtime() and mtkime(). And, yes, the OS on the laptop, at least, is a Single-UNIX-Specification-certified Unix.)
On Jul 5, 2022, at 4:00 PM, Stephen Trainor (Crookneck) <stephen@crookneckconsulting.com> wrote:
I don’t disagree with any of that. However, there are plenty of use cases where you care about the time zone:
- in a place other than your device's current location - where your planned location doesn’t have a good name (e.g. a wilderness area) - and want to be certain which rules are being applied (e.g. Page, AZ and surrounding area), i.e. call it whatever hyperlocal name you want, but I still need to know which TZ rules you're applying (and the TZID is the best proxy, as opposed to trying to read the actual rules).
(I presume the items in that list are separated by "and" rather than "or".) The TZID may be a good proxy for people who are familiar with TZIDs. It might not be for others, e.g. if you're somewhere within the Navajo Nation, a TZID of America/Denver might come as a surprise. "Mountain Time", or "US Mountain Time", might make more sense; in that particular use case, historical time zones are unlikely to be relevant (I'm assuming "planned" here refers to planned time in the future spent at that location, so what that location did for 2 years back in the late 1940's isn't relevant), so a name that currently applies to multiple TZIDs, due to past weirdness and present not-so-weirdness, might make more sense.
"Stephen Trainor (Crookneck) via tz" <tz@iana.org> writes:
True, but clearly there’s major inertia when it comes to changing them, as evidenced by the last several years of debate on K**v. So which is it? Easily mutable identifiers that users supposedly never see or human consumable ‘readable’ IDs?
I think this is a little bit backwards in that nearly all of the demand for mutability comes from the human-consumable property. If it weren't for having to occasionally deal with changes in human naming conventions, there would be no reason to change the identifiers at all, only split them when one shared set of rules diverges. And changing the identifiers is a hassle (and an unwanted distraction into non-time-relevant politics). So I would put the conflict differently. It's a tension between immutable identifiers that would be meaningless to humans and identifiers that have to be mutable because humans derive meaning from them. There's obviously a technical preference for the former, including occasionally advocacy of treating the identifiers as immutable no matter how human-readable they appear to be and letting them diverge from real-world geographic names. But the current reality is that humans do see the identifiers and therefore do care about them. No one was particularly enthused by my suggestion a while back to explicitly use two layers of identifies, one that's immutable UUIDs (or sequential numbers or whatever) representing rule sets, and another that's *only* a mapping from human-readable names to immutable UUIDs that could be maintained by some non-technical body whose raison d'etre is dealing with human political conflicts. Understandably so, since that would add a chunk of infrastructure and additional work to create flexibility where it's not clear that it's needed, and due to backward-compatibility constraints it's not clear if it could even achieve its desired goals. But as a result the tz database continues with the current compromise of sometimes-mutable, human-discouraged identifiers and endless arguments over intent and political responsibility. -- Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>
participants (3)
-
Guy Harris -
Russ Allbery -
Stephen Trainor (Crookneck)