search

tc39 / proposal-intl-locale-info

An API to expose information of locale, such as week data ( first day of a week, weekend start, weekend end), hour cycle, measurement system, commonly used calendar, etc.
MIT License
56 stars 11 forks source link

Possible forward-compatibility issue in Intl.Locale.prototype.getTimeZones()? #73

Closed anba closed 1 year ago

anba commented 3 years ago

get Intl.Locale.prototype.timeZones is spec'ed to return IANA names, so if we ever extend Intl.Locale to support the "tz" Unicode extension, I have to assume that get Intl.Locale.prototype.timeZone will also return the resolved IANA name instead of the "tz" value. For example new Intl.Locale("en-u-tz-usnyc").timeZones will then return ["America/New_York"]. And following that line of thought, I assume new Intl.Locale("en-u-tz-usnyc").timeZone (so singular "timeZone") will then also return "America/New_York", to keep things consistent.

Do we expect that this will cause any issues for users who want to access the actual value "usnyc"?

FrankYFTang commented 3 years ago

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 commented 3 years ago

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

FrankYFTang commented 3 years ago

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

good point. I got confused.

FrankYFTang commented 3 years ago

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

anba commented 3 years ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

I agree with Shane's proposal to use timeZoneIds.

FrankYFTang commented 1 year ago

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.

  1. 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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago
  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.

image
sffc commented 1 year ago

+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 commented 1 year ago

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

FrankYFTang commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

Agree, separate names seems like the way to go.

FrankYFTang commented 1 year ago

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 commented 1 year ago

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:

FrankYFTang commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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:

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 commented 1 year ago

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 commented 1 year ago

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