Time zone needs for calendar application

[leftmostcat]

I am currently working on the calendar functionality in Mozilla Thunderbird, which is built on top of the Firefox codebase. At present, we get most of the functionality we need via ICU4C's C++ API. However, this API is not sufficient to provide everything we need and we'll likely want to transition to ICU4X at some point anyhow. In order to address both problems, I'd like to begin working with ICU folks on designing and implementing the time zone functionality we require for the calendar.

Our basic needs are as follows:

• Allow users to select a time zone in a manner that makes sense to them
• Given an IANA time zone identifier, access sufficient data, both historical and present/future, to construct an RFC 5545-compliant VTIMEZONE definition
• Given an IANA time zone identifier and a date, display a user-friendly time zone (as in the first bullet point) to users

We hope to accomplish this with a combination of IANA tzdb and CLDR data via ICU as follows:

• Enumerate CLDR metazones and their constituent territories; retrieve long generic metazone display names for user locale and localized exemplar locations for each territory (allows us to display, e.g., (UTC-08:00) Pacific Time - Los Angeles or (UTC+05:45) Nepal Time`, localized as appropriate)
• Retrieve time zone definitions either as a series of rules or as a whole cloth VTIMEZONE component string
• Map from tzid and date to a metazone and, if possible, territory

At present, we are doing the following in ICU4C:

• Enumerating canonical time zone IDs via VTimeZone::createTimeZoneIDEnumeration(); note that this doesn't allow us to present time zones in the user-friendly manner described above, and ICU4C currently has no facility for enumerating metazone territories
• Retrieving time zone definitions via VTimeZone::write()

The following bugs filed against ICU4C may be relevant in designing the necessary API:
ICU-22236 Cannot enumerate metazone territories
ICU-22175 VTimeZone::createVTimeZoneByID does not return NULL on unknown ID (to wit, it is necessary to distinguish between Etc/Unknown—a valid IANA alias—and an invalid timezone ID)

[Manishearth]

cc @nordzilla @samchen61661 @sffc for time zone stuff

[zbraniecki]

@leftmostcat thank you for taking time to document your use case needs. This is incredibly helpful for us in shaping the APIs to supply them.

Once the module owners and architects decide on the shape of APIs, we will split this into smaller items to allow people to tackle them separately and identify good-first bugs for contributors.

[nordzilla]

@leftmostcat Thanks so much for creating this issue. This is all incredibly helpful.

I want to go one by one through the things you've listed and address them.

---

Allow users to select a time zone in a manner that makes sense to them.

This criteria is subjective, but I certainly hope that this will be achievable with ICU4X's time-zones APIs.

---

Given an IANA time zone identifier, access sufficient data, both historical and present/future, to construct an RFC 5545-compliant VTIMEZONE definition

I am not familiar with VTIMEZONE, but I took a brief look at the RFC. I think ICU4X should have all of the information available internally to create such a VTIMEZONE object, but at present we don't have plans to expose all of it.

In particular, it looks like this VTIMEZONE object needs access to the list of transitions and rules regarding daylight savings time changes for a particular zone. While ICU4X will have this information to enable ZonedDateTimeFormat to display everything correctly for a given ZonedDateTime, exposing that data publicly is not something that is currently planned as it's not externally needed when invoking DateTimeFormat APIs.

---

Given an IANA time zone identifier and a date, display a user-friendly time zone (as in the first bullet point) to users.

ICU4X should be able to provide satisfactory options here, particularly according to the UTS-35 specification.

---

Enumerate CLDR metazones and their constituent territories.

I'm not sure exactly what you mean here. Metazones are not unique to a territory. Here is an example of one metazone (America/Central) being associated with two different territories in CLDR data.

Do you mean for a given metazone, you want to retrieve a list of all territories associated with that metazone?

---

Retrieve long generic metazone display names for user locale and localized exemplar locations for each territory.

This will certainly be achievable according to the UTS-35 specifications mentioned above.

---

Retrieve time zone definitions either as a series of rules or as a whole cloth VTIMEZONE component string.

We do not currently have plans to expose data in this way.

---

Map from tzid and date to a metazone and, if possible, territory

While this data is available in CLDR, and you will be able to get the correct metazone from the DateTimeFormat APIs, we don't currently have plans to expose the territory information directly.

Can you tell me more about the use case for retrieving territory information specifically?

---

As mentioned above, some of the functionality you mentioned is already on the roadmap to support, but other items are not. But that doesn't mean that we can't have a discussion about supporting them and designing APIs that would provide the most useful information in non-confusing and ergonomic ways.

I'm thrilled that you brought all of this to the table so that we can continue to have discussions about what time-zone-related APIs should exist beyond the scope of ZonedDateTimeFormat itself.

If you have any thoughts, questions or responses, please let me know!

[leftmostcat]

Thanks for your responses! Replies where needed are inline.

This criteria is subjective, but I certainly hope that this will be achievable with ICU4X's time-zones APIs.

I mentioned what this looks like for us below, but I didn't connect it to this need very well. In order to present a user-friendly list of time zones, we want to combine standard UTC offset, metazone long generic name, and—where a metazone covers multiple territories with distinct IANA time zones—the exemplar locations for the territories. We would have time zones such as the following:

• (UTC-08:00) Pacific Time - Los Angeles
• (UTC-08:00) Pacific Time - Tijuana
• (UTC-08:00) Pacific Time - Vancouver
• (UTC+05:45) Nepal Time

I am not familiar with VTIMEZONE, but I took a brief look at the RFC. I think ICU4X should have all of the information available internally to create such a VTIMEZONE object, but at present we don't have plans to expose all of it.

In particular, it looks like this VTIMEZONE object needs access to the list of transitions and rules regarding daylight savings time changes for a particular zone. While ICU4X will have this information to enable ZonedDateTimeFormat to display everything correctly for a given ZonedDateTime, exposing that data publicly is not something that is currently planned as it's not externally needed when invoking DateTimeFormat APIs.

The list of transitions and rules is exactly what we need. In particular, this is a requirement for us as we need to send iCalendar events over the wire, and to ensure compatibility, this means sending the relevant timezone definition as a VTIMEZONE component, so it's not sufficient for us to rely on an underlying library to do the conversions for us.

I'm not sure exactly what you mean here. Metazones are not unique to a territory. Here is an example of one metazone (America/Central) being associated with two different territories in CLDR data.

Do you mean for a given metazone, you want to retrieve a list of all territories associated with that metazone?

Specifically, we want to be able to get the mapZone associations between a metazone and a time zone. This would be used to construct the list as described above. Since metazones don't require these time zones to share daylight behavior to be part of the same metazone, it would be possible for America/Los_Angeles and America/Vancouver to both be in America_Pacific but not be interchangeable. (I don't have concrete examples right now, but as the "metazone" definition in §7.1 of UTS #35 points out, this is explicitly allowed.) We still want the list we provide to the user to be primarily organized by metazone, as we believe it will be generally more recognizable to users, but it's necessary to allow them to choose between the time zones associated with each territory.

[sffc]

If you want to turn "America/Los_Angeles" into "Pacific Time - Los Angeles", you need the metazone and the exemplar city. You don't need a territory for the metazone.

I'm not sure if CLDR offers this style out of the box (metazone + location), but it's not a bad idea.

[leftmostcat]

If you want to turn "America/Los_Angeles" into "Pacific Time - Los Angeles", you need the metazone and the exemplar city. You don't need a territory for the metazone.

I'm not sure if CLDR offers this style out of the box (metazone + location), but it's not a bad idea.

The problem is arriving at "America/Los_Angeles" in the first place. In order to minimize confusing choices, I was hoping to avoid presenting every canonical time zone; for example, "America/Detroit" and "America/New_York" don't differ meaningfully, and I hoped that iterating over the territories mapped in the CLDR would allow preventing this, but in coming up with this example I realized that "America/Phoenix" is not differentiated in any way from the rest of "America_Mountain" and has no associated territory, so this approach may not be workable, in which case we would just need a way to enumerate all canonical time zones. (Would it be helpful to edit above comments?)

[sffc]

for example, "America/Detroit" and "America/New_York" don't differ meaningfully

People who live in Detroit might take offence at that :)

I think the best solution is to just take the whole list of (canonicalized) IANA time zone IDs and format them in the best way. The location format is already supported by ICU4X ("Los Angeles Time"), and I think that your proposed format ("Pacific Time - Los Angeles") could work, too, if proposed.

FYI, you can now get the full list of IANA time zones through ECMA-402 like this:

Intl.supportedValuesOf("timeZone")
(428) ['Africa/Abidjan', 'Africa/Accra', 'Africa/Addis_Ababa', ... ]