This repository has been archived by the owner on Jul 31, 2023. It is now read-only.
AvailableCalendars, AvailableCollations, and AvailableNumberingSystems should return canonical identifiers #37
Comments
|
On the other hand: if we have these operations return aliases as well as canonical identifiers, at least for AvailableCalendars and AvailableTimeZones, then we could write e.g. IsValidTimeZoneName (and IsBuiltinCalendarName, which is upcoming in Temporal) in terms of these operations. With the current definitions of IsValidTimeZoneName and CanonicalizeTimeZoneName, that's not possible. |
|
Note also the current definition of AvailableTimeZones is inconsistent on this account: the description says it returns "a sorted List of supported Zone and Link names in the IANA Time Zone Database" but the algorithm steps start from such a List but only add canonical names to the returned List before sorting it. |
ptomato
added a commit
to tc39/proposal-temporal
that referenced
this issue
Apr 14, 2022
AvailableTimeZones is an abstract operation defined in the Intl.Enumeration proposal. Sharing AvailableTimeZones between ECMA-262 and ECMA-402 should allow us to stipulate that if an implementation supports any time zone for formatting in Intl.DateTimeFormat, it must support it for Temporal as well. Note this is blocked on resolving whether AvailableTimeZones should return only canonicalized names or also backzone names: tc39/proposal-intl-enumeration#37 See: #541 See: #519
ptomato
added a commit
to tc39/proposal-temporal
that referenced
this issue
Apr 14, 2022
AvailableCalendars is an abstract operation defined in the Intl.Enumeration proposal. Sharing AvailableCalendars between ECMA-262 and ECMA-402 should allow us to stipulate that if an implementation supports any calendar for formatting in Intl.DateTimeFormat, it must support it for Temporal as well. Note this is blocked on resolving whether AvailableCalendars should return only canonicalized names or also names like `islamicc` (instead of the canonical `islamic-civil`): tc39/proposal-intl-enumeration#37 See: #541
ptomato
added a commit
to tc39/proposal-temporal
that referenced
this issue
Apr 26, 2022
AvailableCalendars is an abstract operation defined in the Intl.Enumeration proposal. Sharing AvailableCalendars between ECMA-262 and ECMA-402 should allow us to stipulate that if an implementation supports any calendar for formatting in Intl.DateTimeFormat, it must support it for Temporal as well. The operation in the ECMA-402 part may change when it is resolved at some point whether AvailableCalendars should return only canonicalized names or also names like `islamicc` (instead of the canonical `islamic-civil`): tc39/proposal-intl-enumeration#37 Closes: #541
Ms2ger
pushed a commit
to tc39/proposal-temporal
that referenced
this issue
Apr 27, 2022
AvailableCalendars is an abstract operation defined in the Intl.Enumeration proposal. Sharing AvailableCalendars between ECMA-262 and ECMA-402 should allow us to stipulate that if an implementation supports any calendar for formatting in Intl.DateTimeFormat, it must support it for Temporal as well. The operation in the ECMA-402 part may change when it is resolved at some point whether AvailableCalendars should return only canonicalized names or also names like `islamicc` (instead of the canonical `islamic-civil`): tc39/proposal-intl-enumeration#37 Closes: #541
ptomato
added a commit
to tc39/proposal-temporal
that referenced
this issue
May 4, 2022
AvailableTimeZones is an abstract operation defined in the Intl.Enumeration proposal (though there is a small difference, see below.) Sharing AvailableTimeZones between ECMA-262 and ECMA-402 should allow us to stipulate that if an implementation supports any time zone for formatting in Intl.DateTimeFormat, it must support it for Temporal as well. This change means IsValidTimeZoneName is no longer implementation-defined, and does not need to exist in ECMA-402, only in 262. Note, this requires a slightly different algorithm for AvailableTimeZones than the one in the Intl.Enumeration proposal. I have opened an issue for resolving whether AvailableTimeZones should return only canonicalized names or also backzone names: tc39/proposal-intl-enumeration#37 See: #541 See: #519
ptomato
added a commit
to tc39/proposal-temporal
that referenced
this issue
May 5, 2022
AvailableTimeZones is an abstract operation defined in the Intl.Enumeration proposal (though there is a small difference, see below.) Sharing AvailableTimeZones between ECMA-262 and ECMA-402 should allow us to stipulate that if an implementation supports any time zone for formatting in Intl.DateTimeFormat, it must support it for Temporal as well. This change means IsValidTimeZoneName is no longer implementation-defined, and does not need to exist in ECMA-402, only in 262. Note, this requires a slightly different algorithm for AvailableTimeZones than the one in the Intl.Enumeration proposal. I have opened an issue for resolving whether AvailableTimeZones should return only canonicalized names or also backzone names: tc39/proposal-intl-enumeration#37 See: #541 See: #519
ptomato
added a commit
to tc39/proposal-temporal
that referenced
this issue
May 6, 2022
AvailableTimeZones is an abstract operation defined in the Intl.Enumeration proposal (though there is a small difference, see below.) Sharing AvailableTimeZones between ECMA-262 and ECMA-402 should allow us to stipulate that if an implementation supports any time zone for formatting in Intl.DateTimeFormat, it must support it for Temporal as well. This change means IsValidTimeZoneName is no longer implementation-defined, and does not need to exist in ECMA-402, only in 262. Note, this requires a slightly different algorithm for AvailableTimeZones than the one in the Intl.Enumeration proposal. I have opened an issue for resolving whether AvailableTimeZones should return only canonicalized names or also backzone names: tc39/proposal-intl-enumeration#37 See: #541 See: #519
ptomato
added a commit
to tc39/proposal-temporal
that referenced
this issue
May 19, 2022
AvailableTimeZones is an abstract operation defined in the Intl.Enumeration proposal (though there is a small difference, see below.) Sharing AvailableTimeZones between ECMA-262 and ECMA-402 should allow us to stipulate that if an implementation supports any time zone for formatting in Intl.DateTimeFormat, it must support it for Temporal as well. This change means IsValidTimeZoneName is no longer implementation-defined, and does not need to exist in ECMA-402, only in 262. Note, this requires a slightly different algorithm for AvailableTimeZones than the one in the Intl.Enumeration proposal. I have opened an issue for resolving whether AvailableTimeZones should return only canonicalized names or also backzone names: tc39/proposal-intl-enumeration#37 See: #541 See: #519
ptomato
added a commit
to tc39/proposal-temporal
that referenced
this issue
May 19, 2022
AvailableTimeZones is an abstract operation defined in the Intl.Enumeration proposal (though there is a small difference, see below.) Sharing AvailableTimeZones between ECMA-262 and ECMA-402 should allow us to stipulate that if an implementation supports any time zone for formatting in Intl.DateTimeFormat, it must support it for Temporal as well. This change means IsValidTimeZoneName is no longer implementation-defined, and does not need to exist in ECMA-402, only in 262. Note, this requires a slightly different algorithm for AvailableTimeZones than the one in the Intl.Enumeration proposal. I have opened an issue for resolving whether AvailableTimeZones should return only canonicalized names or also backzone names: tc39/proposal-intl-enumeration#37 See: #541 See: #519
ptomato
added a commit
to ptomato/proposal-intl-enumeration
that referenced
this issue
Jul 16, 2022
The Available abstract operations (e.g. AvailableCalendars) should return all possible aliases, so that other places in the spec (e.g. the Temporal.Calendar constructor) can use them to determine whether a given input value is valid. This input value can subsequently be canonicalized by another abstract operation (e.g. CanonicalizeCalendar). In Intl.supportedValuesOf(), on the other hand, we should _not_ return all possible aliases, so we filter them out using a Canonicalize operation before returning the list of Available codes as an array to the caller. Not all of the kinds of codes here have aliases, and not even all of them have a concept of "canonical". A quick investigation shows: - Calendar: aliased; case-regularized; limited values "available" but any well-formed value accepted, unknown values coerced to the locale's default - Collation: not aliased; case-regularized; limited values "available" but any well-formed value accepted, unknown values coerced to the locale's default - Currency: not sure if it is aliased because I don't have a copy of ISO 4217; case-regularized; limited values "available" but any well-formed value accepted and used - Numbering system: not aliased; not case-regularized; limited values "available" but any well-formed value accepted, unknown values coerced to the locale's default - Time zone: aliased; case-regularized - Unit of measurement: not aliased; not case-regularized; limited values "available" but simple combinations of core values also accepted and used So, I conclude that we need Canonicalize operations for calendars, time zones, and possibly currency units. An alternative approach would be to write Canonicalize operations for all of the kinds of codes, and have them perform the case-regularization (or for numbering systems and units of measurement they would be no-ops). Closes: tc39#37
ptomato
added a commit
to tc39/proposal-temporal
that referenced
this issue
Aug 31, 2022
AvailableTimeZones is an abstract operation defined in the Intl.Enumeration proposal (though there is a small difference, see below.) Sharing AvailableTimeZones between ECMA-262 and ECMA-402 should allow us to stipulate that if an implementation supports any time zone for formatting in Intl.DateTimeFormat, it must support it for Temporal as well. This change means IsValidTimeZoneName is no longer implementation-defined, and does not need to exist in ECMA-402, only in 262. Note, this requires a slightly different algorithm for AvailableTimeZones than the one in the Intl.Enumeration proposal. I have opened an issue for resolving whether AvailableTimeZones should return only canonicalized names or also backzone names: tc39/proposal-intl-enumeration#37 See: #541 See: #519
ptomato
added a commit
to ptomato/proposal-intl-enumeration
that referenced
this issue
Sep 8, 2022
The Available abstract operations (e.g. AvailableCalendars) should return all possible aliases, so that other places in the spec (e.g. the Temporal.Calendar constructor) can use them to determine whether a given input value is valid. This input value can subsequently be canonicalized by another abstract operation (e.g. CanonicalizeCalendar). In Intl.supportedValuesOf(), on the other hand, we should _not_ return all possible aliases, so we filter them out using a Canonicalize operation before returning the list of Available codes as an array to the caller. Not all of the kinds of codes here have aliases, and not even all of them have a concept of "canonical". A quick investigation shows: - Calendar: aliased; case-regularized; limited values "available" but any well-formed value accepted, unknown values coerced to the locale's default - Collation: aliased, but web reality is that aliases are ignored; case-regularized; limited values "available" but any well-formed value accepted, unknown values coerced to the locale's default - Currency: not sure if it is aliased because I don't have a copy of ISO 4217; case-regularized; limited values "available" but any well-formed value accepted and used - Numbering system: not currently aliased; not case-regularized; limited values "available" but any well-formed value accepted, unknown values coerced to the locale's default - Time zone: aliased; case-regularized - Unit of measurement: not aliased; not case-regularized; limited values "available" but simple combinations of core values also accepted and used So, I conclude that we need Canonicalize operations for calendars, time zones, collation types, numbering systems, and possibly currency units. An alternative approach would be to write Canonicalize operations for all of the kinds of codes, and have them perform the case-regularization (and for units of measurement they would be no-ops). Closes: tc39#37
ptomato
added a commit
to ptomato/proposal-intl-enumeration
that referenced
this issue
Sep 9, 2022
The Available abstract operations (e.g. AvailableCalendars) should return all possible aliases, so that other places in the spec (e.g. the Temporal.Calendar constructor) can use them to determine whether a given input value is valid. This input value can subsequently be canonicalized by another abstract operation (e.g. CanonicalizeCalendar). In Intl.supportedValuesOf(), on the other hand, we should _not_ return all possible aliases, so we filter them out using a Canonicalize operation before returning the list of Available codes as an array to the caller. Not all of the kinds of codes here have aliases, and not even all of them have a concept of "canonical". A quick investigation shows: - Calendar: aliased; case-regularized; limited values "available" but any well-formed value accepted, unknown values coerced to the locale's default - Collation: aliased, but web reality is that aliases are ignored; case-regularized; limited values "available" but any well-formed value accepted, unknown values coerced to the locale's default - Currency: not sure if it is aliased because I don't have a copy of ISO 4217; case-regularized; limited values "available" but any well-formed value accepted and used - Numbering system: not currently aliased; not case-regularized; limited values "available" but any well-formed value accepted, unknown values coerced to the locale's default - Time zone: aliased; case-regularized - Unit of measurement: not aliased; not case-regularized; limited values "available" but simple combinations of core values also accepted and used So, I conclude that we need Canonicalize operations for calendars, time zones, collation types, numbering systems, and possibly currency units. An alternative approach would be to write Canonicalize operations for all of the kinds of codes, and have them perform the case-regularization (and for units of measurement they would be no-ops). Closes: tc39#37
FrankYFTang
added a commit
that referenced
this issue
Sep 29, 2022
Change the name of the AO better allign with it's intention to prepare to address #37
|
TG2 discussion: https://github.com/tc39/ecma402/blob/master/meetings/notes-2022-10-06.md#intl-enumeration-api-for-stage-4 Conclusion: Merge #43, and then continue discussing opportunities to improve the specification such as #49. |
|
I am closing this since all the work should be done in #43 already. If you spot remaining issue, please open new bug only for that. Thanks |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Similar to tc39/proposal-intl-locale-info#32, AvailableCalendars, AvailableCollations, and AvailableNumberingSystems should all return canonical identifiers. For example AvailableCalendars should canonicalise
"islamicc"to"islamic-civil".The text was updated successfully, but these errors were encountered: