Paul (and to a lesser extent, Brian):

Paul Eggert via tz <[email protected]> wrote on Wed,  3 Dec 2025
at 13:08:28 EST in <[email protected]>:

> More generally, labels like "Indian/Mauritius" should not be exposed to users 
> unfamiliar with the naming
> scheme. See <https://data.iana.org/time-zones/theory.html#naming>, which says:

I do not understand why we persist in pretending this is true when we know it 
is not!
(Other than it sure is convenient for the tz project to not have to worry about 
the consequences of our naming.)

It is kind of offensive, also, to James, given that he wrote:

| This creates misunderstandings when scheduling international
| meetings, especially on platforms like Zoom, Google Calendar, and
| others that rely directly on IANA time zone identifiers.

Are we really telling James that he is supposed to go change Google Calendar. 
AND Zoom?


It sure is convenient for us to pretend that identifiers are not exposed to 
users, but that has never been true.
Yeah, some people use tzselect but other people still have to manipulate 
symbolic links to /etc/localtime, and still others of us do stuff like

  jhawk@lrr ~ % TZ=Europe/London gdate -d "$(TZ=US/Pacific gdate -d 1pm)"
  Wed Dec  3 21:00:00 GMT 2025

with alarming frequency.

But even settng that aside, it is entirely unrealistic for us to suggest that 
users who complain about problems should just fix widespread tools like Google 
Calendar and Zoom.

I think it would be defensible (but still wrong) for us to say we are sorry and 
that we have communicated to the large corporate entities responsible for those 
popular tools used by millions of users our concerns, but...have we even done 
that? (Again, I don't think would be a great thing to do, but it would be 
defensible.)

But, at a minimum, we certainly should not pretend that users like James should 
just use a "simple selection interface" that does not exist in the applications 
they have told us they are using.
And it's not James is using some bespoke tool only used by a tiny fraction of 
the population.


We also should not address end-users like they are developers.

Thanks.

(I removed James from the cc list)

--
[email protected]
John Hawkinson
+1 617 797 0250

> 
> ---
> 
> Inexperienced users are not expected to select these names unaided. 
> Distributors should provide
> documentation and/or a simple selection interface that explains each name via 
> a map or via descriptive
> text like "Czech Republic" instead of the timezone name "Europe/Prague".... 
> Unicode's Common Locale Data
> Repository (CLDR) contains data that may be useful for other selection 
> interfaces....
> 
> ----
> 
> For Indian/Mauritius CLDR gives the names "Mauritius" (English), "Maurice" 
> (French), "سويشيروم" (Arabic),
> "毛里求斯" (Chinese), etc., and users should see these names, not the internal 
> label "Indian/Mauritius".
> 
> 
> >   2.  A documented alias or clarification could be added to help reduce 
> > confusion for end users.
> 
> The three zone*.tab files contain the following clarifying comment; perhaps 
> you could point users at it,
> if they're concerned about the label?
> 
> # This table is intended as an aid for users, to help them select timezones
> # appropriate for their practical needs.  It is not intended to take or
> # endorse any position on legal or territorial claims.


Brian Inglis via tz <[email protected]> wrote on Wed,  3 Dec 2025
at 13:29:03 EST in <[email protected]>:

> Preferably upgrade your interface so it uses localized time zone references 
> from, for example, the

...
> For third party packages, complain bitterly and publicly on their socials 
> about the non-localized
> amateurish interface with a bunch of ASCII English identifiers that they 
> expect users to figure out, as
> they really don't care, rather than a more friendly map or list of nore local 
> gazetteer locations.
...

Reply via email to