On Fri, Nov 5, 2021 at 11:23 AM Ken Murchison via tz <tz@iana.org> wrote:

On 11/5/21 2:18 PM, Eliot Lear via tz wrote:

Just on this point:

On 05.11.21 17:42, Brian Park wrote:

Better to stick with what we have: observe what people on the ground think the time is.

I've seen this a few times, but I don't understand it. No normal person on the ground thinks their time is "America/Los_Angeles". It's "US/Pacific". No normal person in Toronto thinks their time is "America/Toronto". Their country is not even America. They think their timezone is "Canada/Eastern". People are forced to use "America/Los_Angeles" or "America/Toronto" because the TZDB forced that nomenclature upon our users. It seems a mapping layer, like the 'countryzone' file containing ISO-countries, would be the one that provides the timezones that people use on the ground.

Second verse, same as the first: these are database keys, not user interface presentation. Nobody is forced to present any database key to a user. If you have locale awareness, as most modern user-facing systems have, you're going to be far more granular anyway.

Couldn't agree more with Eliot.

The practical reality is that the TZDB identifiers are externally visible identifiers to end-users. The Unix system forces the TZDB identifiers on to the user when I have to type this:

$ TZ=America/Toronto date

I agree that it is conceptually cleaner if the Core TZDB identifiers were internal only. But I understand that some people would consider ISO-country identifiers to be out of scope of this project, although there are many ad hoc ones currently in the database. I think a file like 'countryzone' should be added only if there are people willing to maintain such a list. It may need to be a separate project, to avoid forcing the TZ Coordinator to pick up the slack if those maintainers drop off.

Brian