Skip to content
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

Closed
justingrant opened this issue Jan 18, 2022 · 15 comments
Labels
ecma402 Behavior specific to implementations supporting ecma402 has-consensus non-prod-polyfill THIS POLYFILL IS NOT FOR PRODUCTION USE! spec-text Specification text involved
Milestone

Comments

@justingrant
Copy link
Collaborator

justingrant commented Jan 18, 2022

While working on another fix, I noticed unexpected spec text and polyfill behavior for toLocaleString's calendar and timeZone options.

From js-temporal/temporal-polyfill#118:

the spec and the polyfill also accept a ZDT-like property bag too, per tc39/proposal-temporal#925. Specifically, they accept any object with a timeZone property and will use that property's value as the time zone, with one exception: per tc39/proposal-temporal#925 (comment), recursive bags like {timeZone: {timeZone: 'Asia/Tokyo'}} are disallowed.

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 the calendar or timeZone 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-aware Intl.DateTimeFormat constructor). The spec text for these operations coerce the timeZone or calendar 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 like 2020-01-01T00:00Z[America/Los_Angeles][u-ca=chinese] or an object like Temporal.ZonedDateTime.

Repro:

zdt = Temporal.ZonedDateTime.from('2000-01-01[Asia/Tokyo][u-ca=japanese]');
// => 2000-01-01T00:00:00+09:00[Asia/Tokyo][u-ca=japanese]
zdt2 = Temporal.ZonedDateTime.from({ year: 2000, month: 1, day: 1, calendar: zdt, timeZone: zdt });
// => Temporal.ZonedDateTime <2000-01-01T00:00:00+09:00[Asia/Tokyo][u-ca=japanese]
zdt.toLocaleString('ja-JP', { calendar: zdt, timeZone: zdt });
// => Uncaught RangeError: Invalid calendar : 2000-01-01T00:00:00+09:00[Asia/Tokyo][u-ca=japanese]

The problematic spec text is here:

### for calendars

6. Let calendar be ? GetOption(options, "calendar", "string", undefined, undefined).
7. If calendar is not undefined, then
  a. If calendar does not match the Unicode Locale Identifier type nonterminal, throw a RangeError exception.

### for time zones

32. Else,
  a. Let timeZone be ? ToString(timeZone).
  b. If the result of IsValidTimeZoneName(timeZone) is false, then
    i. Throw a RangeError exception.
@justingrant justingrant added spec-text Specification text involved non-prod-polyfill THIS POLYFILL IS NOT FOR PRODUCTION USE! ecma402 Behavior specific to implementations supporting ecma402 labels Jan 18, 2022
@ptomato
Copy link
Collaborator

ptomato commented Jan 18, 2022

This is difficult, because these are Intl's calendar and timeZone options, not Temporal's: https://devdocs.io/javascript/global_objects/intl/datetimeformat/datetimeformat
As such, they only accept strings, and would not be able to handle custom calendars and time zones.

I agree this is a confusing inconsistency though. Any ideas on how to solve it?

@justingrant
Copy link
Collaborator Author

A possible way to address this could be for the various toLocaleString implementations to check to see calendar or timeZone options are objects, and if they are then handle the string coercion on the Temporal side. This would fix toLocaleString so at least any Temporal API would be consistent, even if it'd be inconsistent with Intl. This approach would require cloning the options object before handing off to Intl, so I'm not sure if that would cause more problems than it solves.

The other option would be for Intl to also accept property bag inputs too for calendar and timeZone options.

Neither option handles custom calendars/timezones and I think that's OK.

@sffc @ryzokuken @gibson042 what do you think?

@sffc
Copy link
Collaborator

sffc commented Jan 18, 2022

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

@justingrant
Copy link
Collaborator Author

justingrant commented Jan 19, 2022

@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-toLocaleString Temporal API:

  1. a built-in calendar ID string
  2. a Temporal.Calendar instance
  3. a CalendarProtocol object that's not a Temporal.Calendar instance
  4. any Temporal instance that carries a calendar property
  5. any object with a calendar property whose value is (1), (2), or (3).
  6. a valid ISO string (if there's no calendar annotation, then the ISO calendar will be used)

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 CalendarProtocol doesn't include text localization features.

But currently (4), (5), and (6) don't work with .toLocaleString() on Temporal objects or with new DateTimeFormat(). Should they?

@sffc
Copy link
Collaborator

sffc commented Jan 19, 2022

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.

@justingrant
Copy link
Collaborator Author

Meeting 2022-01-20: property bag calendar and timeZone options should work in toLocaleString as well as Intl.DateTimeFormat constructor. Should review this with TG2.

@FrankYFTang
Copy link
Contributor

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.

@justingrant
Copy link
Collaborator Author

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 });

justingrant added a commit to justingrant/temporal-polyfill that referenced this issue Feb 3, 2022
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.
justingrant added a commit to js-temporal/temporal-polyfill that referenced this issue Feb 4, 2022
…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.
@sffc
Copy link
Collaborator

sffc commented Feb 10, 2022

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

@justingrant
Copy link
Collaborator Author

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]

@justingrant justingrant changed the title In .toLocaleString() options, property-bag form of calendar and timeZone will throw In .toLocaleString() options, property-bag or ISO string forms of calendar and timeZone will throw Feb 13, 2022
@justingrant justingrant changed the title In .toLocaleString() options, property-bag or ISO string forms of calendar and timeZone will throw Normative: In .toLocaleString() options, property-bag or ISO string forms of calendar and timeZone will throw Mar 3, 2022
justingrant added a commit to justingrant/proposal-temporal that referenced this issue Mar 18, 2022
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.
justingrant added a commit to justingrant/proposal-temporal that referenced this issue Mar 18, 2022
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
justingrant added a commit to justingrant/proposal-temporal that referenced this issue Mar 18, 2022
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
justingrant added a commit to justingrant/proposal-temporal that referenced this issue Mar 18, 2022
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
justingrant added a commit to justingrant/proposal-temporal that referenced this issue Mar 18, 2022
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
justingrant added a commit to justingrant/proposal-temporal that referenced this issue Mar 18, 2022
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
justingrant added a commit to justingrant/proposal-temporal that referenced this issue Mar 18, 2022
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
@ptomato ptomato removed this from the Next batch of normative changes milestone Dec 8, 2022
@ptomato ptomato added this to the Stage "3.5" milestone Dec 8, 2022
@ptomato
Copy link
Collaborator

ptomato commented Dec 8, 2022

Re-assess this after landing the solution to #1808. Intl.DateTimeFormat doesn't support custom objects, so maybe strings are sufficient after all.

@justingrant
Copy link
Collaborator Author

justingrant commented Jan 5, 2023

Meeting 2023-01-05: @sffc would prefer to discuss this in 402. At his request I filed tc39/ecma402#741.

@justingrant
Copy link
Collaborator Author

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.

@ptomato
Copy link
Collaborator

ptomato commented Apr 10, 2023

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 calendar or timeZone options. When this is changed on the ECMA-402 side, if Temporal is not yet Stage 4, we'll pull that change in before submitting the Stage 4 PR.

@ptomato ptomato closed this as completed Apr 10, 2023
@justingrant
Copy link
Collaborator Author

justingrant commented May 1, 2023

Now that #2522 is merged, the TimeZone part of this issue for toLocaleString doesn't matter because the timeZone option is disallowed from ZonedDateTime.p.toLocaleString. The remaining case for toLocaleString is calendar-only. Like this:

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 Intl.DateTimeFormat, both calendar and timeZone cases still apply.

@justingrant justingrant changed the title Normative: In .toLocaleString() options, property-bag or ISO string forms of calendar and timeZone will throw Normative: In .toLocaleString() options, Temporal object or ISO string forms of calendar and timeZone will throw May 12, 2023
@justingrant justingrant changed the title Normative: In .toLocaleString() options, Temporal object or ISO string forms of calendar and timeZone will throw Normative: In .toLocaleString() options, Temporal object or ISO string forms of calendar and timeZone options will throw May 12, 2023
@justingrant justingrant changed the title Normative: In .toLocaleString() options, Temporal object or ISO string forms of calendar and timeZone options will throw Normative: In InitializeDateTimeFormat options, Temporal object or ISO string forms of calendar and timeZone will throw May 12, 2023
@justingrant justingrant changed the title Normative: In InitializeDateTimeFormat options, Temporal object or ISO string forms of calendar and timeZone will throw Normative: In InitializeDateTimeFormat options, Temporal object or ISO string forms of calendar and timeZone will throw May 12, 2023
justingrant added a commit to justingrant/proposal-temporal that referenced this issue May 12, 2023
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
justingrant added a commit to justingrant/proposal-temporal that referenced this issue May 12, 2023
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
justingrant added a commit to justingrant/proposal-temporal that referenced this issue May 12, 2023
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
justingrant added a commit to justingrant/proposal-temporal that referenced this issue May 13, 2023
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
justingrant added a commit to justingrant/proposal-temporal that referenced this issue May 13, 2023
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
justingrant added a commit to justingrant/proposal-temporal that referenced this issue May 13, 2023
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
justingrant added a commit to justingrant/proposal-temporal that referenced this issue May 13, 2023
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
justingrant added a commit to justingrant/proposal-temporal that referenced this issue May 13, 2023
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
justingrant added a commit to justingrant/proposal-temporal that referenced this issue May 13, 2023
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
justingrant added a commit to justingrant/proposal-temporal that referenced this issue May 14, 2023
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
justingrant added a commit to justingrant/proposal-temporal that referenced this issue May 14, 2023
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
justingrant added a commit to justingrant/proposal-temporal that referenced this issue May 14, 2023
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
justingrant added a commit to justingrant/proposal-temporal that referenced this issue May 16, 2023
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ecma402 Behavior specific to implementations supporting ecma402 has-consensus non-prod-polyfill THIS POLYFILL IS NOT FOR PRODUCTION USE! spec-text Specification text involved
Projects
None yet
4 participants