New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Normative: In InitializeDateTimeFormat
options, Temporal object or ISO string forms of calendar
and timeZone
will throw
#2005
Comments
This is difficult, because these are Intl's calendar and timeZone options, not Temporal's: https://devdocs.io/javascript/global_objects/intl/datetimeformat/datetimeformat I agree this is a confusing inconsistency though. Any ideas on how to solve it? |
A possible way to address this could be for the various The other option would be for Intl to also accept property bag inputs too for Neither option handles custom calendars/timezones and I think that's OK. @sffc @ryzokuken @gibson042 what do you think? |
In my opinion: Given that Temporal is going into 262, and 402 assumes 262 exists, what I'd eventually like to get to is a world where the normative spec text for DateTimeFormat operates on upgraded Temporal objects. The downgrading to String that we currently do is a hack. That should be limited to perhaps the resolvedOptions impl on DateTimeFormat, but the internal slot can rightfully be a Temporal object. CC @FrankYFTang |
@sffc I'm not sure I understand your comment so will try to clarify. Today, all of the following are acceptable for a calendar (time zone has same behavior too) parameter to any non-
My reading of your comment above is that you're talking about (2). Is that correct? Obviously (3) and the (3)-dependent case of (5) won't work because But currently (4), (5), and (6) don't work with |
Yes. Everything that we are coercing to a Calendar in Temporal should also be coerced in Intl.DateTimeFormat. My comment was regarding this section: https://tc39.es/proposal-temporal/#sec-properties-of-intl-datetimeformat-instances We say "[[Calendar]] is a String value" and "[[TimeZone]] is a String value". I think we should consider generalizing these to be Temporal instances stored in the internal slots. If we did this, then the above question about coercion follows. However, the two questions are decoupled. |
Meeting 2022-01-20: property bag |
It seems to me that what is required is to create the necessary ECMA402 changes into a PR toward https://tc39.es/proposal-temporal/#sec-temporal-intl and present such PR to TG2 also. |
For whoever PRs this change, here's some code (copied from #925 (comment)) that can be used for tests. I'm not sure if there's already Test262 coverage for the non-Intl uses of bag inputs, so I pasted those below too. bag = { year: 2020, month: 1, day: 1, timeZone: 'Asia/Tokyo', calendar: 'japanese' };
zdt = Temporal.ZonedDateTime.from(bag);
instant = Temporal.Instant.from('2020-01-01T00:00Z');
plainDate = Temporal.PlainDate.from('2020-01-01');
plainTime = Temporal.PlainTime.from('00:00');
plainTime.toZonedDateTime({ timeZone: bag, plainDate });
instant.toZonedDateTime({ timeZone: 'Europe/London', calendar: bag});
instant.toZonedDateTime({ timeZone: bag, calendar: 'japanese' });
instant.toString({ timeZone: bag });
// the code below will currently throw, but if #2005 is approved then it won't throw
plainDate.toLocaleString('ja-JP', { timeZone: bag, calendar: bag });
new DateTimeFormat('ja-JP', { timeZone: bag, calendar: bag }); |
Extends TS tsupport for property-bag form of Calendar-like and TimeZone-like params in Temporal methods. Fixes js-temporal#118 Also allows `Temporal.Calendar` instances to be used in the `Intl.DateTimeFormatOptions` type. (Previously only string IDs were allowed. Fixes js-temporal#124. Note that fixing tc39/proposal-temporal#2005 will further extend the types that can be passed into the `calendar` and `timeZone` properties of `Intl.DateTimeFormatOptions`. But that requires a spec change and polyfill code change, so in this commit we'll only extend `Intl.DateTimeFormatOptions` to what's supported by the current spec and polyfill.
…nd polyfill (#126) * Update TimeZone-like/Calendar-like types Extends TS tsupport for property-bag form of Calendar-like and TimeZone-like params in Temporal methods. Fixes #118 Also allows `Temporal.Calendar` instances to be used in the `Intl.DateTimeFormatOptions` type. (Previously only string IDs were allowed. Fixes #124. Note that fixing tc39/proposal-temporal#2005 will further extend the types that can be passed into the `calendar` and `timeZone` properties of `Intl.DateTimeFormatOptions`. But that requires a spec change and polyfill code change, so in this commit we'll only extend `Intl.DateTimeFormatOptions` to what's supported by the current spec and polyfill. * Remove now-unnecessary casts With the type updates in this PR, a few type casts are not needed. See https://github.com/js-temporal/temporal-polyfill/pull/109/files#r780638159 for more context.
Discussion 2022-02-10: https://github.com/tc39/ecma402/blob/master/meetings/notes-2022-02-10.md#in-tolocalestring-options-property-bag-form-of-calendar-and-timezone-will-throw-2005 Conclusion: JGT: We will extend the annex of Temporal spec to support this, due the consensus we have here |
In addition to property bags, ISO strings don't work either. I assume the same problem happens with time zones and calendars, although I only tested calendars. s = '2020-04-25[u-ca=islamic]';
date = Temporal.PlainDate.from(s);
date.toLocaleString('en-US', { calendar: s });
// expected: no error
// actual: RangeError: Invalid calendar : 2020-04-25[u-ca=islamic] |
.toLocaleString()
options, property-bag form of calendar
and timeZone
will throw.toLocaleString()
options, property-bag or ISO string forms of calendar
and timeZone
will throw
.toLocaleString()
options, property-bag or ISO string forms of calendar
and timeZone
will throw.toLocaleString()
options, property-bag or ISO string forms of calendar
and timeZone
will throw
This commit makes the `calendar` and `timeZone` options in the `Intl.DateTimeFormat` constructor and Temporal types' `toLocaleString` methods (which are implemented using a common abstract operation) accept the same types as other Temporal methods that accept a calendar or time zone parameter. Fixes tc39#2005. Before this commit, the only types accepted by these localization methods were: * string IDs of the calendar or time zone * Temporal.TimeZone or Temporal.Calendar instances, because they can be coerced to string IDs. This commit adds support for the following to match the behavior of other Temporal methods: * ISO strings, e.g. 2020-01-01T00:00-05:00[Asia/Tokyo][u-ca=japanese] * property bags e.g. {year: 2020, month: 1, day: 1, calendar: 'chinese'} * other Temporal types that have a `calendar` or `timeZone` property, e.g. Temporal.PlainDate or Temporal.ZonedDateTime Note that accepting ISO strings for PlainMonthDay and PlainYearMonth are broken due to tc39#2105, so tests for those string formats are skipped.
This commit makes the `calendar` and `timeZone` options in the `Intl.DateTimeFormat` constructor and Temporal types' `toLocaleString` methods (which are implemented using a common abstract operation) accept the same types as other Temporal methods that accept a calendar or time zone parameter. Fixes tc39#2005. Before this commit, the only types accepted by these localization methods were: * string IDs of the calendar or time zone * Temporal.TimeZone or Temporal.Calendar instances, because they can be coerced to string IDs. This commit adds support for the following to match the behavior of other Temporal methods: * ISO strings, e.g. 2020-01-01T00:00-05:00[Asia/Tokyo][u-ca=japanese] * property bags e.g. {year: 2020, month: 1, day: 1, calendar: 'chinese'} * other Temporal types that have a `calendar` or `timeZone` property, e.g. Temporal.PlainDate or Temporal.ZonedDateTime
This commit makes the `calendar` and `timeZone` options in the `Intl.DateTimeFormat` constructor and Temporal types' `toLocaleString` methods (which are implemented using a common abstract operation) accept the same types as other Temporal methods that accept a calendar or time zone parameter. Fixes tc39#2005. Before this commit, the only types accepted by these localization methods were: * string IDs of the calendar or time zone * Temporal.TimeZone or Temporal.Calendar instances, because they can be coerced to string IDs. This commit adds support for the following to match the behavior of other Temporal methods: * ISO strings, e.g. 2020-01-01T00:00-05:00[Asia/Tokyo][u-ca=japanese] * property bags e.g. {year: 2020, month: 1, day: 1, calendar: 'chinese'} * other Temporal types that have a `calendar` or `timeZone` property, e.g. Temporal.PlainDate or Temporal.ZonedDateTime
This commit makes the `calendar` and `timeZone` options in the `Intl.DateTimeFormat` constructor and Temporal types' `toLocaleString` methods (which are implemented using a common abstract operation) accept the same types as other Temporal methods that accept a calendar or time zone parameter. Fixes tc39#2005. Before this commit, the only types accepted by these localization methods were: * string IDs of the calendar or time zone * Temporal.TimeZone or Temporal.Calendar instances, because they can be coerced to string IDs. This commit adds support for the following to match the behavior of other Temporal methods: * ISO strings, e.g. 2020-01-01T00:00-05:00[Asia/Tokyo][u-ca=japanese] * property bags e.g. {year: 2020, month: 1, day: 1, calendar: 'chinese'} * other Temporal types that have a `calendar` or `timeZone` property, e.g. Temporal.PlainDate or Temporal.ZonedDateTime
This commit makes the `calendar` and `timeZone` options in the `Intl.DateTimeFormat` constructor and Temporal types' `toLocaleString` methods (which are implemented using a common abstract operation) accept the same types as other Temporal methods that accept a calendar or time zone parameter. Fixes tc39#2005. Before this commit, the only types accepted by these localization methods were: * string IDs of the calendar or time zone * Temporal.TimeZone or Temporal.Calendar instances, because they can be coerced to string IDs. This commit adds support for the following to match the behavior of other Temporal methods: * ISO strings, e.g. 2020-01-01T00:00-05:00[Asia/Tokyo][u-ca=japanese] * property bags e.g. {year: 2020, month: 1, day: 1, calendar: 'chinese'} * other Temporal types that have a `calendar` or `timeZone` property, e.g. Temporal.PlainDate or Temporal.ZonedDateTime
This commit makes the `calendar` and `timeZone` options in the `Intl.DateTimeFormat` constructor and Temporal types' `toLocaleString` methods (which are implemented using a common abstract operation) accept the same types as other Temporal methods that accept a calendar or time zone parameter. Fixes tc39#2005. Before this commit, the only types accepted by these localization methods were: * string IDs of the calendar or time zone * Temporal.TimeZone or Temporal.Calendar instances, because they can be coerced to string IDs. This commit adds support for the following to match the behavior of other Temporal methods: * ISO strings, e.g. 2020-01-01T00:00-05:00[Asia/Tokyo][u-ca=japanese] * property bags e.g. {year: 2020, month: 1, day: 1, calendar: 'chinese'} * other Temporal types that have a `calendar` or `timeZone` property, e.g. Temporal.PlainDate or Temporal.ZonedDateTime
This commit makes the `calendar` and `timeZone` options in the `Intl.DateTimeFormat` constructor and Temporal types' `toLocaleString` methods (which are implemented using a common abstract operation) accept the same types as other Temporal methods that accept a calendar or time zone parameter. Fixes tc39#2005. Before this commit, the only types accepted by these localization methods were: * string IDs of the calendar or time zone * Temporal.TimeZone or Temporal.Calendar instances, because they can be coerced to string IDs. This commit adds support for the following to match the behavior of other Temporal methods: * ISO strings, e.g. 2020-01-01T00:00-05:00[Asia/Tokyo][u-ca=japanese] * property bags e.g. {year: 2020, month: 1, day: 1, calendar: 'chinese'} * other Temporal types that have a `calendar` or `timeZone` property, e.g. Temporal.PlainDate or Temporal.ZonedDateTime
Re-assess this after landing the solution to #1808. Intl.DateTimeFormat doesn't support custom objects, so maybe strings are sufficient after all. |
Meeting 2023-01-05: @sffc would prefer to discuss this in 402. At his request I filed tc39/ecma402#741. |
Meeting 2023-01-12: We'll wait for 402 to fix this on the Intl side. In the meantime, toLocaleString methods will not support passing non-calendar/tz Temporal objects nor ISO strings. |
After landing #2482, I believe nothing more needs to be done here. We have defined what happens with calendar and time zone objects from Temporal objects' internal slots, and ECMA-402 defines what happens with values passed as |
Now that #2522 is merged, the TimeZone part of this issue for pd = Temporal.PlainDate.from('2000-01-01');
pdJapanese = pd.withCalendar('japanese');
pd.toLocaleString('ja-JP', { calendar: pdJapanese });
// => RangeError: Invalid calendar : 2000-01-01[u-ca=japanese] For |
.toLocaleString()
options, property-bag or ISO string forms of calendar
and timeZone
will throw.toLocaleString()
options, Temporal object or ISO string forms of calendar
and timeZone
will throw
.toLocaleString()
options, Temporal object or ISO string forms of calendar
and timeZone
will throw.toLocaleString()
options, Temporal object or ISO string forms of calendar
and timeZone
options will throw
.toLocaleString()
options, Temporal object or ISO string forms of calendar
and timeZone
options will throwcalendar
and timeZone
will throw
calendar
and timeZone
will throwInitializeDateTimeFormat
options, Temporal object or ISO string forms of calendar
and timeZone
will throw
This commit changes InitializeDateTimeFormat to accept the same types as other Temporal methods that accept a calendar or time zone parameter. Fixes tc39#2005. Before this commit, the only types accepted by these localization methods were: * string IDs of the calendar or time zone * Temporal.TimeZone or Temporal.Calendar instances, because they can be coerced to string IDs. This commit adds support for the following to match the behavior of other Temporal methods: * ISO strings, e.g. 2020-01-01T00:00-05:00[Asia/Tokyo][u-ca=japanese] * other Temporal types that have a `calendar` or `timeZone` property, e.g. Temporal.PlainDate or Temporal.ZonedDateTime
This commit changes InitializeDateTimeFormat to accept the same types as other Temporal methods that accept a calendar or time zone parameter. Fixes tc39#2005. Before this commit, the only types accepted by these localization methods were: * string IDs of the calendar or time zone * Temporal.TimeZone or Temporal.Calendar instances, because they can be coerced to string IDs. This commit adds support for the following to match the behavior of other Temporal methods: * ISO strings, e.g. 2020-01-01T00:00-05:00[Asia/Tokyo][u-ca=japanese] * other Temporal types that have a `calendar` or `timeZone` property, e.g. Temporal.PlainDate or Temporal.ZonedDateTime
This commit changes InitializeDateTimeFormat to accept the same types as other Temporal methods that accept a calendar or time zone parameter. Fixes tc39#2005. Before this commit, the only types accepted by these localization methods were: * string IDs of the calendar or time zone * Temporal.TimeZone or Temporal.Calendar instances, because they can be coerced to string IDs. This commit adds support for the following to match the behavior of other Temporal methods: * ISO strings, e.g. 2020-01-01T00:00-05:00[Asia/Tokyo][u-ca=japanese] * other Temporal types that have a `calendar` or `timeZone` property, e.g. Temporal.PlainDate or Temporal.ZonedDateTime
This commit changes InitializeDateTimeFormat to accept the same types as other Temporal methods that accept a calendar or time zone parameter. Fixes tc39#2005. Before this commit, the only types accepted by these localization methods were: * string IDs of the calendar or time zone * Temporal.TimeZone or Temporal.Calendar instances, because they can be coerced to string IDs. This commit adds support for the following to match the behavior of other Temporal methods: * ISO strings, e.g. 2020-01-01T00:00-05:00[Asia/Tokyo][u-ca=japanese] * other Temporal types that have a `calendar` or `timeZone` property, e.g. Temporal.PlainDate or Temporal.ZonedDateTime
This commit changes InitializeDateTimeFormat to accept the same types as other Temporal methods that accept a calendar or time zone parameter. Fixes tc39#2005. Before this commit, the only types accepted by these localization methods were: * string IDs of the calendar or time zone * Temporal.TimeZone or Temporal.Calendar instances, because they can be coerced to string IDs. This commit adds support for the following to match the behavior of other Temporal methods: * ISO strings, e.g. 2020-01-01T00:00-05:00[Asia/Tokyo][u-ca=japanese] * other Temporal types that have a `calendar` or `timeZone` property, e.g. Temporal.PlainDate or Temporal.ZonedDateTime
This commit changes InitializeDateTimeFormat to accept the same types as other Temporal methods that accept a calendar or time zone parameter. Fixes tc39#2005. Before this commit, the only types accepted by these localization methods were: * string IDs of the calendar or time zone * Temporal.TimeZone or Temporal.Calendar instances, because they can be coerced to string IDs. This commit adds support for the following to match the behavior of other Temporal methods: * ISO strings, e.g. 2020-01-01T00:00-05:00[Asia/Tokyo][u-ca=japanese] * other Temporal types that have a `calendar` or `timeZone` property, e.g. Temporal.PlainDate or Temporal.ZonedDateTime
This commit changes InitializeDateTimeFormat to accept the same types as other Temporal methods that accept a calendar or time zone parameter. Fixes tc39#2005. Before this commit, the only types accepted by these localization methods were: * string IDs of the calendar or time zone * Temporal.TimeZone or Temporal.Calendar instances, because they can be coerced to string IDs. This commit adds support for the following to match the behavior of other Temporal methods: * ISO strings, e.g. 2020-01-01T00:00-05:00[Asia/Tokyo][u-ca=japanese] * other Temporal types that have a `calendar` or `timeZone` property, e.g. Temporal.PlainDate or Temporal.ZonedDateTime
This commit changes InitializeDateTimeFormat to accept the same types as other Temporal methods that accept a calendar or time zone parameter. Fixes tc39#2005. Before this commit, the only types accepted by these localization methods were: * string IDs of the calendar or time zone * Temporal.TimeZone or Temporal.Calendar instances, because they can be coerced to string IDs. This commit adds support for the following to match the behavior of other Temporal methods: * ISO strings, e.g. 2020-01-01T00:00-05:00[Asia/Tokyo][u-ca=japanese] * other Temporal types that have a `calendar` or `timeZone` property, e.g. Temporal.PlainDate or Temporal.ZonedDateTime
This commit changes InitializeDateTimeFormat to accept the same types as other Temporal methods that accept a calendar or time zone parameter. Fixes tc39#2005. Before this commit, the only types accepted by these localization methods were: * string IDs of the calendar or time zone * Temporal.TimeZone or Temporal.Calendar instances, because they can be coerced to string IDs. This commit adds support for the following to match the behavior of other Temporal methods: * ISO strings, e.g. 2020-01-01T00:00-05:00[Asia/Tokyo][u-ca=japanese] * other Temporal types that have a `calendar` or `timeZone` property, e.g. Temporal.PlainDate or Temporal.ZonedDateTime
This commit changes InitializeDateTimeFormat to accept the same types as other Temporal methods that accept a calendar or time zone parameter. Fixes tc39#2005. Before this commit, the only types accepted by these localization methods were: * string IDs of the calendar or time zone * Temporal.TimeZone or Temporal.Calendar instances, because they can be coerced to string IDs. This commit adds support for the following to match the behavior of other Temporal methods: * ISO strings, e.g. 2020-01-01T00:00-05:00[Asia/Tokyo][u-ca=japanese] * other Temporal types that have a `calendar` or `timeZone` property, e.g. Temporal.PlainDate or Temporal.ZonedDateTime
This commit changes InitializeDateTimeFormat to accept the same types as other Temporal methods that accept a calendar or time zone parameter. Fixes tc39#2005. Before this commit, the only types accepted by these localization methods were: * string IDs of the calendar or time zone * Temporal.TimeZone or Temporal.Calendar instances, because they can be coerced to string IDs. This commit adds support for the following to match the behavior of other Temporal methods: * ISO strings, e.g. 2020-01-01T00:00-05:00[Asia/Tokyo][u-ca=japanese] * other Temporal types that have a `calendar` or `timeZone` property, e.g. Temporal.PlainDate or Temporal.ZonedDateTime
This commit changes InitializeDateTimeFormat to accept the same types as other Temporal methods that accept a calendar or time zone parameter. Fixes tc39#2005. Before this commit, the only types accepted by these localization methods were: * string IDs of the calendar or time zone * Temporal.TimeZone or Temporal.Calendar instances, because they can be coerced to string IDs. This commit adds support for the following to match the behavior of other Temporal methods: * ISO strings, e.g. 2020-01-01T00:00-05:00[Asia/Tokyo][u-ca=japanese] * other Temporal types that have a `calendar` or `timeZone` property, e.g. Temporal.PlainDate or Temporal.ZonedDateTime
This commit changes InitializeDateTimeFormat to accept the same types as other Temporal methods that accept a calendar or time zone parameter. Fixes tc39#2005. Before this commit, the only types accepted by these localization methods were: * string IDs of the calendar or time zone * Temporal.TimeZone or Temporal.Calendar instances, because they can be coerced to string IDs. This commit adds support for the following to match the behavior of other Temporal methods: * ISO strings, e.g. 2020-01-01T00:00-05:00[Asia/Tokyo][u-ca=japanese] * other Temporal types that have a `calendar` or `timeZone` property, e.g. Temporal.PlainDate or Temporal.ZonedDateTime
While working on another fix, I noticed unexpected spec text and polyfill behavior for
toLocaleString
'scalendar
andtimeZone
options.From js-temporal/temporal-polyfill#118:
The above is also true for calendars.
Update 2022-02-13: looks like the same spec text also breaks using ISO strings like
"2020-04-25[Europe/Paris][u-ca=islamic]"
for thecalendar
ortimeZone
options.Update 2023-05-12: property bag forms of these options are no longer supported. So this issue is now scoped to just Temporal objects and ISO strings.
But AFAICT, a timezone-like or calendar-like object is currently accepted in all places where a TimeZone instance and timezone/calendar ID string are accepted... except
toLocaleString
methods (and the Temporal-awareIntl.DateTimeFormat
constructor). The spec text for these operations coerce thetimeZone
orcalendar
option to a string, and then use that string. But if the option is an ISO string or a ZonedDateTime or Plain* instance, then InitializeDateTimeFormat will throw because coercing the option to a string yields something that will never be a timezone nor calendar ID.I'm assuming that this is a spec bug, because AFAIK our intent was that all places where a calendar or time zone is required will either accept a
Temporal.Calendar
/Temporal.TimeZone
instance, a string ID, an ISO string like2020-01-01T00:00Z[America/Los_Angeles][u-ca=chinese]
or an object like Temporal.ZonedDateTime.Repro:
The problematic spec text is here:
The text was updated successfully, but these errors were encountered: