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.)