Request for Clarification or Alternative Label for “Indian/Mauritius” Time Zone
Hello, I hope you are well. I am writing regarding the naming of the IANA time zone “Indian/Mauritius.” Many users in Mauritius have reported confusion because the word “Indian” is often interpreted as referring to India rather than the Indian Ocean region. This creates misunderstandings when scheduling international meetings, especially on platforms like Zoom, Google Calendar, and others that rely directly on IANA time zone identifiers. I understand that renaming time zones is avoided due to compatibility concerns. However, I would like to kindly ask whether: 1. An alternative label such as “IndianOcean/Mauritius” could be considered, or 2. A documented alias or clarification could be added to help reduce confusion for end users. Even a non-breaking solution (e.g., an alias) would greatly help clarify the intended meaning without disrupting existing systems. Thank you for your time and for maintaining this important global standard. Kind regards, Kind regards, [cid:asset3_0cde460c-bb22-4017-a4dd-b19716304dc9.png] James Lai IT | Head of Operations Intercontinental Trust Limited Level 3, Alexander House, 35 Cybercity, Ebene 72201, Mauritius E: jlai@intercontinentaltrust.com<mailto:jlai@intercontinentaltrust.com> W: www.intercontinentaltrust.com<http://www.intercontinentaltrust.com/> T: (230) 403 0800 DID: (230) 403 0869 M: (230) 5258 5889 F: (230) 403 0801 BRN: C07023546 [cid:itl_emailbanner_03.10.25v2_d5878fa8-0af2-4ccb-b63e-55a10f1a1c87.jpg] Intercontinental Trust Ltd is regulated by the Financial Services Commission in Mauritius. If you are not the intended recipient, please advise the sender immediately and delete this message. [cid:facebooklogo_9db4cba5-e3da-4106-9849-2d5d2e6d37db.gif]<https://www.facebook.com/IntercontinentalTrust?fref=ts> [cid:LinkedInlogo_86f1ad59-c943-4f8d-a70a-699b2322ca7e.gif] <http://www.linkedin.com/company/2502998?trk=pro_other_cmpy> [cid:Twitterlogo_3b4b7685-ec4d-4906-8971-931729a1de68.gif] <https://twitter.com/ITLMauritius> Disclaimer<http://intercontinentaltrust.com/disclaimer> Please consider the environment before you print
On Wed, 3 Dec 2025 at 12:40, James Lai via tz <tz@iana.org> wrote:
A documented alias or clarification could be added to help reduce confusion for end users.
The general nomenclature is documented in the first section of tz-link.html <https://data.iana.org/time-zones/tz-link.html>, which reads, in part: "Timezones are typically identified by continent or ocean and then by the name of the largest city within the region containing the clocks." -- Tim Parenti
On 2025-12-03 00:01, James Lai via tz wrote:
1. An alternative label such as “IndianOcean/Mauritius” could be considered, or
Unfortunately not likely, as the existing labels are longstanding and adding an "IndianOcean" alias would be more likely to cause than lessen problems. For example, we'd have to deal with many labels, not just "Indian/Mauritius". (Of course you're free to add whatever extra aliases you like in your own copy of TZDB.) 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: --- 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.
I also wanted to give some advices about dealing with these ids from software development perspective (instead of changing the de-facto standard), but the OPs issues is with commonly-used software (Zoom and Google Calendar). Yhough, I cannot say that I've seen plain IANA ids in the software specifically mentioned in the original message, to be honest.
On 2025-12-03 01:01, James Lai via tz wrote:
I hope you are well. I am writing regarding the naming of the IANA time zone *“Indian/Mauritius.” *
Many users in Mauritius have reported confusion because the word *“Indian”* is often interpreted as referring to *India* rather than the *Indian Ocean* region. This creates misunderstandings when scheduling international meetings, especially on platforms like Zoom, Google Calendar, and others that rely directly on IANA time zone identifiers.
I understand that renaming time zones is avoided due to compatibility concerns. However, I would like to kindly ask whether:
1. An alternative label such as *“IndianOcean/Mauritius”* could be considered, or 2. A documented alias or clarification could be added to help reduce confusion for end users.
Even a non-breaking solution (e.g., an alias) would greatly help clarify the intended meaning without disrupting existing systems.
Thank you for your time and for maintaining this important global standard.
Hi, See https://data.iana.org/time-zones/theory.html#naming Preferably upgrade your interface so it uses localized time zone references from, for example, the Unicode International Components for Unicode interface package (using the Unicode Common Locale Data Repository info) in the users' preferred language, rather than raw tz db identifers, never intended for display to users, as nowadays the most populous city (at some point in the past) using that zone may not necessarily be in the local region or may be in a different country, or else document and explain the continent or ocean and largest city usage to your users. In your case, the selection list could perhaps start with "Local Mauritius Time", before dumping a list of ASCII English identifiers in front of your users. 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. I know I am (and probably some others are) looking at how best to migrate to provide only data for the shortest set of currently effective time zones now (internally zonenow.tab), which will be the most populous city (at some point in the past) somewhere (else - mostly) in the world, where that time zone's rules matches the local time zone rules from now on. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut -- Antoine de Saint-Exupéry
Paul (and to a lesser extent, Brian): Paul Eggert via tz <tz@iana.org> wrote on Wed, 3 Dec 2025 at 13:08:28 EST in <5598e61a-c55a-4600-a37b-8ea5d36f26b3@cs.ucla.edu>:
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) -- jhawk@alum.mit.edu 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 <tz@iana.org> wrote on Wed, 3 Dec 2025 at 13:29:03 EST in <5be5cdbc-13a0-472c-8db4-ea07ecf46000@SystematicSW.ab.ca>:
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. ...
Quoting John Hawkinson via tz on Wednesday December 03, 2025:
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.
Some years back, when we identified a spate of government regulators making time zone policy changes on short notice, we started some explicit outreach to governments to send messages on what best practices are and the consequences of doing it poorly. It is something we've reinforced periodically when we speak with governments around the typical shift into and out of daylight saving time. Would a similar approach to software vendors be desirable, particuarly notable applications that have a large audience that use naked TZ identifiers, to encourage them to do something else? If so, what is the guidance? I don't think pointing merely pointing to a theory file is going to move the needle but a more tailored set of guidance on best practices, what implementation options are available like the CLDR, case studies on user interface patterns, and other resources may be helpful. ICANN has general engagement activities with software vendors in areas like universal acceptance of Internet identifiers and adoption of emerging technical standards. Maybe if there are talking points around this can be added to the litany of things they do outreach on. If there are particularly egregious examples that need correction we can try and get it on their radar on a case-by-case basis. kim
On 2025-12-03 11:36, Kim Davies via tz wrote:
Some years back, when we identified a spate of government regulators making time zone policy changes on short notice, we started some explicit outreach to governments to send messages on what best practices are and the consequences of doing it poorly. It is something we've reinforced periodically when we speak with governments around the typical shift into and out of daylight saving time.
Yes, and I've tried to do that sort of thing as recently as this week, although the corporation that runs Nunavik hasn't returned my calls....
Would a similar approach to software vendors be desirable, particuarly notable applications that have a large audience that use naked TZ identifiers, to encourage them to do something else? If so, what is the guidance?
Good idea. Currently the only guidance we have is something along the lines of "Be like tzselect, except nicer with CLDR and/or maps". Which is admittedly vague. And the guidance is not well organized. It'd be helpful to add discussion to theory.html or tz-link.html (or even a new page) that gives more detailed advice. Ideally there would be a reference implementation that does both CLDR and maps, and we could point developers at that implementation. All this would be some work, though.
ICANN has general engagement activities with software vendors in areas like universal acceptance of Internet identifiers and adoption of emerging technical standards. Maybe if there are talking points around this can be added to the litany of things they do outreach on.
Thanks, I didn't know that. Is that litany public? How can suggestions for improvements be made?
On 2025-12-03 13:53, Paul Eggert via t z wrote:
On 2025-12-03 11:36, Kim Davies via tz wrote:
Some years back, when we identified a spate of government regulators making time zone policy changes on short notice, we started some explicit outreach to governments to send messages on what best practices are and the consequences of doing it poorly. It is something we've reinforced periodically when we speak with governments around the typical shift into and out of daylight saving time.
Yes, and I've tried to do that sort of thing as recently as this week, although the corporation that runs Nunavik hasn't returned my calls....
It looks now as if it may be an organization with a corporate governance structure, with ownership in government subsidized or owned enterprises, but staff appear to be drawn mainly from the population of the fourteen N QC Inuit villages/small towns. You might have better luck if you care to call the Montreal office, and that may be more likely to have English (and Inuktitut) speakers available: https://www.makivvik.ca/contact/ tel:+1-800-361-7052 tel:+1-514-745.8880 Better may be Air Inuit, also based in Montreal, which has published email addresses, and is responsible for giving IATA SSIM adequate notice of any time zone or schedule changes which could affect air operations of any flight at any terminal: https://www.airinuit.com/en/about-air-inuit/contact-us mailto:airinuit.info@airinuit.com tel:+1-800-361-5933 tel:+1-514-905-9445 Also interested may be N CA mobile operator Ice Wireless, which has served 3G/4G/LTE GSM across Nunavik since 2019, part of Iristel, based in Markham ON, and would probably like to avoid time zone issues for N QC customers, so having correctly updated time zone info available, before any changes came into effect, would be in their and their customers best interests. The only info is their web pages for their ticketing system and accessibility: https://www.icewireless.com/complaints mailto:customercare@icewireless.com https://www.icewireless.com/accessibility Accessibility button mailto:accessibility@icewireless.ca tel:+1-855-474-7423
Would a similar approach to software vendors be desirable, particuarly notable applications that have a large audience that use naked TZ identifiers, to encourage them to do something else? If so, what is the guidance?
Good idea. Currently the only guidance we have is something along the lines of "Be like tzselect, except nicer with CLDR and/or maps". Which is admittedly vague. And the guidance is not well organized.
It'd be helpful to add discussion to theory.html or tz-link.html (or even a new page) that gives more detailed advice. Ideally there would be a reference implementation that does both CLDR and maps, and we could point developers at that implementation. All this would be some work, though.
Less work would be ICU middleware which uses the CLDR infrastructure, and could probably be more easily leveraged to handle gazetteers and map coordinates: these are all Unicode I18N open source products.
ICANN has general engagement activities with software vendors in areas like universal acceptance of Internet identifiers and adoption of emerging technical standards. Maybe if there are talking points around this can be added to the litany of things they do outreach on.
Thanks, I didn't know that. Is that litany public? How can suggestions for improvements be made?
Suggest vendor apps localize or internationalize access to time zone selection in time, calendar, and scheduling components, possibly using facilities provided by Unicode ICU and CLDR products, to avoid exposing end users to tzdb identifiers. Apps also have to check if the underlying tzdb identifiers would change if the underlying tzdb version changes, and how to handle that. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut -- Antoine de Saint-Exupéry
On 2025-12-03 12:36, Kim Davies via tz wrote:
Quoting John Hawkinson via tz on Wednesday December 03, 2025:
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.
Some years back, when we identified a spate of government regulators making time zone policy changes on short notice, we started some explicit outreach to governments to send messages on what best practices are and the consequences of doing it poorly. It is something we've reinforced periodically when we speak with governments around the typical shift into and out of daylight saving time.
Would a similar approach to software vendors be desirable, particuarly notable applications that have a large audience that use naked TZ identifiers, to encourage them to do something else? If so, what is the guidance? I don't think pointing merely pointing to a theory file is going to move the needle but a more tailored set of guidance on best practices, what implementation options are available like the CLDR, case studies on user interface patterns, and other resources may be helpful.
ICANN has general engagement activities with software vendors in areas like universal acceptance of Internet identifiers and adoption of emerging technical standards. Maybe if there are talking points around this can be added to the litany of things they do outreach on. If there are particularly egregious examples that need correction we can try and get it on their radar on a case-by-case basis.
Mozilla Thunderbird Calendar (formerly Lightning) still uses some previous unspecified tzdb id list in its time interfaces even on Windows! Could at least use and display Windows zone and list with CLDR WindowsZones.xml (via ICU?) to convert. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut -- Antoine de Saint-Exupéry
On 2025-12-03 10:41, John Hawkinson wrote:
More generally, labels like "Indian/Mauritius" should not be exposed to users unfamiliar with the naming scheme.... I do not understand why we persist in pretending this is true when we know it is not!
I wrote "users unfamiliar with the naming scheme" not "end users". An application does these users a real disservice if it merely shows labels without any further advice or documentation. Such an application cannot be expected to work well.
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?
He shouldn't need to. I just now tried both applications, and neither showed me "Indian/Mauritius" among my selections. Google Calendar's menu had an entry "(GMT+04:00) Mauritius Standard Time". Zoom's menu didn't list Mauritius so I suppose users are expected to select its "(GMT+4:00) Dubai" or "(GMT+4:00) Muscat" or "(GMT+4:00) Baku, Tbilisi, Yerevan" entries - not the best UI but it's not TZDB's problem. Although there may be other parts of those applications where users can enter raw TZDB labels, it's still good advice to do that sort of thing only if you know what you're doing. I agree that too many systems ask naive users to use TZDB labels. However, this doesn't mean we should get into the business of maintaining lots (and there will be lots) of aliases to minimize pain for these naive users. That's beyond our capacity and expertise, and CLDR is a better home for that sort of thing.
some people use tzselect but other people still have to manipulate symbolic links to /etc/localtime
The vast majority of users do neither. They use a graphical interface that uses either a map or localized names. Yes, expert users need to know TZDB labels, but they don't need further aliases to do their jobs.
participants (8)
-
Brian Inglis -
brian.inglis＠systematicsw.ab.ca
-
James Lai -
John Hawkinson -
Kim Davies -
Kirill Gagarski -
Paul Eggert -
Tim Parenti