Possible forward-compatibility issue in Intl.Locale.prototype.getTimeZones()? about proposal-intl-locale-info

[FrankYFTang]

I think such concern is already in the Status Quo with the singular .timeZone, right? Assuming we do not have this proposal, we also need to address the issue for .timeZone (singular) which is pre-exist in ECMA402. I think the same resolution could just be applied to .timeZones .

[anba]

There's no singular timeZone property on Intl.Locale, though.

[FrankYFTang]

There's no singular timeZone property on Intl.Locale, though.

good point. I got confused.

[FrankYFTang]

I am not sure what would be a good action item for this issue

[anba]

I think if I were in your shoes, I'd simply present this issue at the next ECMA-402 meeting, so more folks can chime in. The two most likely outcomes are:

1. Leave things as is. And if we ever add support to retrieve the plain "tz" value (like for example usnyc), we'll simply add another accessor with a different name than timeZone.
2. Pick a different name, so that a possible future accessor for plain "tz" values can be named timeZone.

I don't even know if anyone actually has any opinion on this particular issue.

[FrankYFTang]

This issue was filed under many assumptions which is hard to discuss before resolving them first. The core issues based on

1. Would we ever support "-u-tz-" keyword/value in ECMA402?
2. How would we support "-u-tz-" keyword/value in ECMA402? Would the value be treated as a separated Internal slot or using the same internal slot in DateTimeFormat
   Currently, the [[TimeZone]] Internal slot in DateTimeFormat is defined as
   "[[TimeZone]] is a String value that is a time zone identifier from the IANA Time Zone Database used for formatting."
   https://tc39.es/ecma402/#sec-properties-of-intl-datetimeformat-instances
   which is not possible to contain those five letters tz value defined in UTS35 (short) Time Zone Identifiers

which is really a totally different name space

Therefore, I transfer this issue to ECMA402 for the consideration and leave this issue for whoever champion to add the support to read "tz" extension in Unicode Locale identifier to solve. I think likely that will be stored in a different internal slot and access via a different name if that will ever happen.

[sffc]

I wasn't aware of this issue.

I agree it would be nice to not take the name timeZones when there is a BCP-47 tag of the same name with different semantics, even if we don't currently support it and have no short or medium term plans to support it.

I suggest one of the following:

1. timeZoneIds can return IANA names and is consistent with the .timeZoneId getter on Temporal objects
2. getTimeZones() could be a function returning upgraded Temporal.TimeZone instances

I suggest (1) to unblock the Intl Locale Info proposal.

CC @justingrant

[justingrant]

I agree with Shane's proposal to use timeZoneIds.

[FrankYFTang]

I suggest one of the following:

1. timeZoneIds can return IANA names and is consistent with the .timeZoneId getter on Temporal objects

It return an Array - which is an object, therefore, it cannot be a getter. but a function. We have discussed this early this year. It must be a getXXX function. I do not think we should go back to rediscuss this again.

2. getTimeZones() could be a function returning upgraded Temporal.TimeZone instances

I think that should be done in a proposal which allow the Intl.DateTimeFormat to take Temporal.TimeZone as parameter for the timeZone option bag instead of in the Intl Locale Info API proposal.

[FrankYFTang]

Also in https://www.unicode.org/reports/tr35/#UnicodeTimezoneIdentifier the issue @anba referring to is the "Short identifiers", Not "Time Zone Identifier"

"The short identifiers are defined in the file common/bcp47/timezone.xml."

[FrankYFTang]

I agree it would be nice to not take the name timeZones when there is a BCP-47 tag of the same name with different semantics

But Intl.DateTimeFormat constructor and Intl.DateTimeFormat.prototype.resolvedOptons() ALREADY take the name "timeZone" YEARS ago.

[FrankYFTang]

a BCP-47 tag of the same name with different semantics

This is not true. Not the SAME name. The name for BCP-47 tz name is "Short Identifier" not "Time Zone Identifier", as mentioned in the UTS 35.

[justingrant]

1. timeZoneIds can return IANA names and is consistent with the .timeZoneId getter on Temporal objects

It return an Array - which is an object, therefore, it cannot be a getter. but a function. We have discussed this early this year. It must be a getXXX function. I do not think we should go back to rediscuss this again.

Makes sense. getTimeZoneIds() would be fine, assuming that the result is an array of IANA IDs and not CLDR short codes. I would not support getTimeZones() because it seems too similar with Temporal.ZonedDateTime's getTimeZone() method that returns a Temporal.TimeZone object.

I think that should be done in a proposal which allow the Intl.DateTimeFormat to take Temporal.TimeZone as parameter for the timeZone option bag instead of in the Intl Locale Info API proposal.

FWIW, this case is already supported, because if timeZone is an Object, then it's coerced to a String, which returns the id of the TimeZone. I guess there could be an improvement that adds a fast path to avoid the observable Get. But if the goal is simply to support TimeZone objects in DTF, then there's no action needed beyond the current spec.

[sffc]

+1 on getTimeZoneIds()

I think the precedent of the Intl.DateTimeFormat field called timeZone is not very strong because we are taking an approach that this option coerces its inputs to a better form, such as calling ToString on the Temporal.TimeZone type. However, this getter on Intl.Locale will only ever return exactly one format (IANA names as strings).

[FrankYFTang]

@anba what is your view about changing it to getTimeZoneIds() since you are the one who filed this issue.

[FrankYFTang]

I am not quite sure how would renaming this to getTimeZoneIds() will address the forward-compatibility issue @anba is filing about.
In that world, if one day we do support let loc = new Intl.Locale("en-u-tz-usnyc")

then
a. what getter will return "usnyc" ? and
b. what getter will return "America/New_York"?

[gibson042]

For both this issue and #70, I am comfortable with ECMA-402 objects supporting multiple namespaces (Unicode vs. IANA here, Unicode vs. ISO 8601 in #70), provided that each is associated with a distinct property name and (for input) inconsistency and possibly also non-inconsistent redundancy is rejected. For example, new Intl.Locale("en-u-tz-usnyc") might produce an object for which getTimeZoneIds() returns an array containing "America/New_York" and unicodeShortTimeZone returns "usnyc", as would new Intl.Locale("en-u-tz-uslax", { timeZone: "America/New_York" }) and new Intl.Locale("en-u-tz-uslax", { unicodeShortTimeZone: "usnyc" }) per the already-established pattern of options data taking precedence over language tag data.

[sffc]

Yeah, I'm convinced that if/when we add support for Unicode-style time zone IDs, we should give them a very clearly unique namespace, such as unicodeShortTimeZone or timeZoneBcp47Id or similar.

[justingrant]

Agree, separate names seems like the way to go.

[FrankYFTang]

OK, we have several options to resolve this issue

1. Agree we will use a different method name to return the "Unicode-style time zone IDs" if one day we decide to support it. therefore
2. Decide the name for the IANA

Option A- Keep the prospoal as is, getTimeZones() return an array (therefore it is an object) which contains Strings
Option B- Rename that getTimeZones() to getTimeZoneIds()

As a stage 3 proposal. My understanding is according to https://tc39.es/process-document/
"Post-Acceptance Changes Expected" for Stage 3 is
"Limited: only those deemed critical based on implementation experience"

Therefore, unless we have a implementer find a critical issue based on " implementation experience" we should not make such change. Is there a case showing us that is the case now?

As v8 implementer, I do NOT feel it is a "critical based on implementation experience" to rename it. It will be nice if we have implementater for other engines or library to speak about their " implementation experience".

[sffc]

I'll note that this issue was opened by @anba (an implementer). There is also new information since this reached Stage 3, which is that Temporal only recently decided to go with timeZoneId.

I think the only real options are getTimeZones() and getTimeZoneIds(). They have pros and cons:

• Advantages of getTimeZones():
  • Consistency with Intl.DateTimeFormat's timeZone option
  • Consistency with Intl.supportedValuesOf("timeZone")
  • Current state of the Stage 3 proposal
• Advantages of getTimeZoneIds():
  • Consistency with Temporal
  • More clear that this function is returning time zone IDs, not Temporal.TimeZone objects
  • Leaves the getTimeZones() name open for future proposals

[FrankYFTang]

The point @anba made while filing this bug is not about getTimeZones vs getTimeZoneIds but how to deal with "tz" Unicode extension in the future and that issue exist regardless how we name this function between getTimeZones and getTimeZoneIds, right?

[sffc]

getTimeZoneIds() is consistent with timeZoneId in Temporal which is defined as an IANA time zone, leaving getTimeZones() open if we wanted to make it either BCP-47 or Temporal.TimeZone objects.

I think there's probably room for -u-tz to change the content of the returned list like we do for Collations and Calendars and others.

[anba]

@anba what is your view about changing it to getTimeZoneIds() since you are the one who filed this issue.

Changing getTimeZones() to getTimeZoneIds() based on Temporal kind of ignores Intl.Locale.prototype.getCalendars() and calendarId in Temporal.

The following advantages for getTimeZoneIds() were mentioned:

• It's consistent with timeZoneId in Temporal and allows to add Intl.Locale.prototype.getTimeZones() which returns an array of Temporal.TimeZone objects. (#73 (comment))
• getTimeZones() is too similar to Temporal.ZonedDateTime.prototype.getTimeZone(). (#73 (comment))

But these points all also apply to Intl.Locale.prototype.getCalendars(). (The only difference is that we already have Intl.Locale.prototype.calendar, which returns a String value.)

[FrankYFTang]

We discussed this in 2023-09-07 TG2, and attendees supprt keeping the current spec text with getTimeZones() and getCalendars() without changing it to Ids() suffix.

[sffc]

TG2 notes: https://github.com/tc39/ecma402/blob/master/meetings/notes-2023-09-07.md#possible-forward-compatibility-issue-in-intllocaleprototypegettimezones-73