js-temporal/temporal-polyfill (@js-temporal/polyfill)
### [`v0.4.4`](https://redirect.github.com/js-temporal/temporal-polyfill/blob/HEAD/CHANGELOG.md#044)
[Compare Source](https://redirect.github.com/js-temporal/temporal-polyfill/compare/v0.4.3...v0.4.4)
Breaking changes:
- `Temporal.ZonedDateTime` objects are no longer supported as parameters to `Intl.DateTimeFormat` formatting methods. (\[[`12071fb`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/12071fb0)], see also [Upstream PR](https://redirect.github.com/tc39/proposal-temporal/pull/2479), [Upstream PR 2](https://redirect.github.com/tc39/proposal-temporal/pull/2522))
- To format using `Temporal.ZonedDateTime`'s time zone, use `Temporal.ZonedDateTime.prototype.toLocaleString`. This method:
1. Creates a new `Intl.DateTimeFormat` instance in the same time zone and calendar as the `Temporal.ZonedDateTime` instance
2. Creates a `Temporal.Instant` from the `Temporal.ZonedDateTime` instance.
3. Formats that `Temporal.Instant` instance using the created `Intl.DateTimeFormat` instance.
- To format in a time zone that does not match the time zone of the `Temporal.ZonedDateTime` instance:
1. Create a new `Temporal.ZonedDateTime` instance in the right time zone using `Temporal.ZonedDateTime.prototype.withTimeZone`.
- To get the current system time zone, use `Temporal.Now.timeZoneId()`.
Be careful when caching the current system time zone (or an `Intl.DateTimeFormat` instance using that time zone), because the system time zone can change during the lifetime of your program (e.g. when a user on a mobile device crosses a time zone boundary or when a user manually edits time zone settings).
2. Follow the steps above.
- Generally, try to always include the `timeZone` property when creating an `Intl.DateTimeFormat` instance to avoid an ambiguity about which time zone the formatted results will be in.
- `Intl.DateTimeFormat` instances can be expensive to create. For performance-sensitive code where the same calendar and time zone are used repeatedly for formatting, we recommend creating and reusing an `Intl.DateTimeFormat` instance with the desired `timeZone` and `calendar` options, and then formatting using the value of `Temporal.ZonedDateTime.prototype.epochMilliseconds`.
`Intl.DateTimeFormat` instances may also require a lot of RAM, so indefinitely caching large numbers of them is not recommended for memory-constrained environments.
- The `.calendar` property on Temporal types has been replaced with a `.calendarId` property that returns the string calendar identifier and a `.getCalendar()` method that returns an object that implements `Temporal.CalendarProtocol`.
- `getCalendar()` will always return a new object if the containing instance was constructed using a built-in calendar identifier string. However, if the containing instance was constructed using a calendar object (either a built-in calendar or custom calendar), then the same object is returned. (\[[`cc701b4`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/cc701b45)], see also [Upstream issue](https://redirect.github.com/tc39/proposal-temporal/issues/1808))
- Temporal will compare calendars by testing for string equality between calendar identifiers.
When a calendar is an object, its `id` property will be used for comparison. (\[[`3916e54`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/3916e547)], see also [Upstream issue](https://redirect.github.com/tc39/proposal-temporal/issues/1808))
- The `.calendar` property has been entirely removed from `Temporal.PlainTime`. (\[[`0727d86`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/0727d86e)], see also [Issue 1](https://redirect.github.com/tc39/proposal-temporal/issues/1808), [Issue 2](https://redirect.github.com/tc39/proposal-temporal/issues/1588))
- The `.timeZone` property on `Temporal.ZonedDateTime` has been replaced with a `.timeZoneId` property that returns the string time zone identifier and a `.getTimeZone()` method that returns an object that implements `Temporal.TimeZoneProtocol`. (\[[`d3263f0`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/d3263f0)], see also Upstream issue)
- `getTimeZone()` will always return a new object if the `Temporal.ZonedDateTime` instance was constructed using a built-in time zone identifier string.
However, if the instance was constructed using a time zone object (either a built-in time zone or custom time zone), then the same object is returned.
- `Termporal.Now.timeZone()` is replaced by `Temporal.Now.timeZoneId()`, which returns a time zone identifier string, not a `Temporal.TimeZone` instance. (\[[`600f0cc`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/600f0cc7)], see also [Upstream issue](https://redirect.github.com/tc39/proposal-temporal/issues/1808))
- Temporal will compare time zones by testing for string equality between calendar identifiers.
When a calendar is an object, its `id` property will be used for comparison. (\[[`d6cb286`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/d6cb2862)], see also [Upstream issue](https://redirect.github.com/tc39/proposal-temporal/issues/1808))
- Require the `id` property and make overriding `toString` optional (but recommended!) for `Temporal.TimeZoneProtocol`. (\[[`97637bb`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/97637bbc)])
- Remove support for nested time zone and calendar property bags. (\[[`9b7f61a`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/9b7f61ae)], \[[`0c38267`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/0c38267b)], see also [Discussion](https://redirect.github.com/tc39/proposal-temporal/issues/2104#issuecomment-140))
- Require the remainder returned by the `NanosecondsToDays` internal operation to be less than the length of one calendar day.
This could happen due to shenanigans in a custom time zone's `getOffsetNanosecondsFor` or `getPossibleInstantsFor` methods, or a custom calendar's `dateAdd` method.
(\[[`44b00a3`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/44b00a38)], see also [Upstream issue](https://redirect.github.com/tc39/proposal-temporal/issues/2357)
- Set an upper limit of 1e9 on rounding increments. (\[[`5d78c81`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/5d78c815)])
- Require `fields` and `mergeFields` methods for `Temporal.CalendarProtocol` (custom calendar) objects. (\[[`5ad6327`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/5ad63274)])
- Reject Z designators when parsing `Temporal.PlainTime` strings.
Bug fixes:
- Read field identifiers from a calendar's `fields()` method during `dateFromFields()`, `yearMonthFromFields()`, and `monthDayFromFields()`.
Previously, these methods only referenced hardcoded `'era'` and `'eraYear'` field identifiers. (\[[`375a4ad`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/375a4ad9)])
- Avoid precision loss in AddDuration operations. (\[[`c0f7349`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/c0f7349a)])
- Fix an infinite-loop bug and a RangeError during non-ISO calendar calculations. (\[[`d94c1cd`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/d94c1cd9)], see also [proposal-temporal PR](https://redirect.github.com/tc39/proposal-temporal/pull/2539), [Issue 1](https://redirect.github.com/tc39/proposal-temporal/issues/2383), [Issue 2](https://redirect.github.com/tc39/proposal-temporal/issues/2537))
- Avoid rounding errors in `BalanceTime` operations. (\[[`9260a8a`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/9260a8a0)])
- Avoid precision loss in `NanosecondsToDays` operations. (\[[`e02f062`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/e02f0626)])
- Require that results from `NanosecondsToDays` calls don't flip sign. (\[[`0b238cc`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/0b238ccf)])
- Fix bugs introduced while restricting the creation of `Temporal.Duration` using non-numeric inputs. (\[[`46c4132`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/46c4132d)], see also [Upstream issue](https://redirect.github.com/tc39/proposal-temporal/issues/2112))
- Fix bugs when passing fractional numbers to `CreateTemporalDuration`. (\[[`856a546`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/856a5460)], see also [Upstream issue](https://redirect.github.com/tc39/proposal-temporal/issues/2246))
- Always return a Number of nanoseconds from `RoundDuration`. (\[[`8d3c1f1`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/8d3c1f1b)])
- Use BigInt math in `RoundDuration` to avoid problems when the values are larger than `Number.MAX_SAFE_INTEGER`. (\[[`955323f`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/955323f8)])
- Always start at the end of 1972 when computing a `Temporal.PlainMonthDay` from fields, preventing the reference year from accidentally being in 1971. (\[[`ef4a0c4`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/ef4a0c4b)])
- Apply the overflow behaviour to year/month/day values in `monthDayFromFields`. (\[[`7ebd0f9`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/7ebd0f96)])
- Preserve the day of month when constraining a nonexistent leap month, instead of defaulting to the end of the closest corresponding regular month. (\[[`996f8fa`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/996f8fa1)])
- Allow month codes `'M01L'` and `'M12L'` in the Chinese calendar. (\[[`696f2c7`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/696f2c7e)])
- Avoid overflows in `GetNamedTimeZoneOffsetNanoseconds`. (\[[`c42570b`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/c42570b8)])
- Fix calendar validation in various ToTemporal\_\_\_ operations. (\[[`e391397`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/e3913974)], see also [Upstream issue](https://redirect.github.com/tc39/proposal-temporal/issues/2546))
- Don't call `GetMethod` on a string calendar. (\[[`fe698d8`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/fe698d8d)], see also [Upstream issue](https://redirect.github.com/tc39/proposal-temporal/pull/2547))
- Avoid rounding errors in `BalanceDurationRelative` and `UnbalanceDurationRelative`. (\[[`a907acf`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/a907acf0)])
- Check for negative day length in `Temporal.ZonedDateTime.prototype.round`. (\[[`0d2d60e`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/0d2d60ec)], see also [Spec PR](https://redirect.github.com/tc39/proposal-temporal/pull/2261))
This change avoids a common bug where a UTC timestamp is accidentally interpreted as if it were a local time in a real time zone.
If you do want to parse the time portion of a UTC timestamp string, use: `Temporal.Instant.from(s).toZonedDateTimeISO('UTC').toPlainTime()`. (\[[`a7a50ea`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/a7a50eac)])
- Reject 0-value components when parsing `Temporal.Duration` strings, and avoid rounding errors when nanoseconds components are present. (\[[`58b5601`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/58b5601a)])
- Reject `relativeTo` string options that are neither valid `Temporal.PlainDate` nor `Temporal.ZonedDateTime` strings, such as `'2022-08-18T17:01Z'`. (\[[`4db15c4`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/4db15c41)])
- Add validation for the return values from calendar operations. (\[[`d88cfa4`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/d88cfa4d)])
- Validate required methods of `Temporal.TimeZoneProtocol` and `Temporal.CalendarProtocol`. (\[[`84563ce`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/84563cea)], \[[`755c762`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/755c7620)], see also [Discussion](https://redirect.github.com/tc39/proposal-temporal/issues/2104#issuecomment-140))
- Throw earlier when users might mix up positional `Temporal.TimeZone` and `Temporal.Calendar` arguments with each other, to prevent bugs like `new Temporal.ZonedDateTime(0n, cal, tz)` where the switched calendar and time zone arguments would cause exceptions to be thrown later. (\[[`7922f1f`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/7922f1f9)])
Non-breaking changes:
- Implement `yearOfWeek` methods that complement existing `weekOfYear` methods.
The new method returns the year associated with `weekOfYear`, which may (see https://en.wikipedia.org/wiki/ISO_week_date) vary from `year` in some calendars like `'iso8601'`.
This new method can be useful for formatting IS0 8601 strings using the year-week-day format like `1981-W53-7`. (\[[`bf08ca5`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/bf08ca56)])
- Support new Internet Extended Date-Time (IXDTF) Annotations
- See the [Temporal + IXDTF tracking issue](https://redirect.github.com/tc39/proposal-temporal/issues/1450).
- Align ISO 8601 grammar with annotations from IXDTF specification.
Calendar and time zone annotations are now allowed to contain a "critical" flag (`'!'`) prefix.
Critical flags have no effect when parsing input strings because Temporal already treats unknown or inconsistent inputs as errors by default. (\[[`e8b2e71`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/e8b2e71c)])
- There can be multiple types of annotations in an IXDTF string.
Temporal only recognizes time zone and calendar annotations.
Unrecognized non-critical annotations will be ignored.
Unrecognized critical annotations will cause the parsing method to throw an exception.
- Allow `toString()` methods for `Temporal.PlainDate`, `Temporal.PlainDateTime`, `Temporal.PlainYearMonth`, `Temporal.PlainMonthDay`, and `Temporal.ZonedDateTime` to emit critical IXDTF annotations using the `'critical'` option.
Use this option with care, because the platform that you're communicating with may not understand this syntax.
`calendarName: 'critical'` behaves like `calendarName: 'always'` and `timeZoneName: 'critical'` behaves like `timeZoneName: 'always'`, but they also output a `'!'` prefix in the corresponding annotation. (\[[`50a64f1`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/50a64f16)])
Critical flags are never used by Temporal, but could be consumed by other programs.
- Ignore calendar annotations when parsing `Temporal.Instant` strings. (\[[`b86b87f`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/b86b87f0)])
- Allow calendar and/or time zone annotations after strings without a time part: YYYY-MM-DD, YYYY-MM, and MM-DD. (\[[`acd6464`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/acd6464f)])
- Disallow UTC offsets in YYYY-MM and MM-DD strings because they could cause ambiguity between an offset and the day of a YYYY-MM-DD string. (\[[`acd6464`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/acd6464f)])
- Reject ambiguous time strings even with calendar annotations. (\[[`af87527`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/af875275)])
- Implement the full set of rounding modes.
New modes include `'expand'`, `'halfCeil'`, `'halfFloor'`, `'halfTrunc'`, and `'halfEven'`.
(\[[`eb5404d`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/eb5404d1)])
- Treat calendar names as case-insensitive. (\[[`9e730d6`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/9e730d68)])
- Improve cross-binary compatibility of polyfill objects by storing internals on `globalThis`. (\[[`73a0bf3`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/73a0bf36)], see also [GitHub Issue](https://redirect.github.com/js-temporal/temporal-polyfill/issues/164))
- Allow various `Temporal.Calendar` methods to return 0. (\[[`8a49023`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/8a49023b)])
- Improve error messages when converting fields to a `Temporal.PlainMonthDay`. (\[[`e1cd417`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/e1cd4170)])
- Round towards the Big Bang in epoch time getters. (\[[`6d124a5`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/6d124a56)], see also [Upstream issue](https://redirect.github.com/tc39/proposal-temporal/issues/2423), [Spec change](https://redirect.github.com/tc39/proposal-temporal/issues/2424))
- Improve performance when operating on large numbers in `BalanceISODate`. (\[[`d2a23dd`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/d2a23dd5)])
- Optimize `Temporal.TimeZone.prototype.getNextTransition()` for dates that predate 1847, which is the earliest data in the IANA time zone database. (\[[`9591af3`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/9591af3b)])
- Improve performance when out-of-range finding transition points for named time zones. (\[[`3b61abf`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/3b61abfe)])
- Special-case zones with precomputed DST transition points in `GetPreviousTransition`. (\[[`5922bdf`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/5922bdf1)])
Other:
- Bump required dependency versions. (\[[`c65455a`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/c65455a5)])
- Fix sourcemaps so they point directly to TS source files. (\[[`6b462d4`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/6b462d49)], see also [GitHub PR](https://redirect.github.com/js-temporal/temporal-polyfill/pull/194))
Configuration
📅 Schedule: Branch creation - "every weekend" in timezone Asia/Tokyo, Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
[ ] If you want to rebase/retry this PR, check this box
This PR contains the following updates:
0.4.3->0.4.4Release Notes
js-temporal/temporal-polyfill (@js-temporal/polyfill)
### [`v0.4.4`](https://redirect.github.com/js-temporal/temporal-polyfill/blob/HEAD/CHANGELOG.md#044) [Compare Source](https://redirect.github.com/js-temporal/temporal-polyfill/compare/v0.4.3...v0.4.4) Breaking changes: - `Temporal.ZonedDateTime` objects are no longer supported as parameters to `Intl.DateTimeFormat` formatting methods. (\[[`12071fb`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/12071fb0)], see also [Upstream PR](https://redirect.github.com/tc39/proposal-temporal/pull/2479), [Upstream PR 2](https://redirect.github.com/tc39/proposal-temporal/pull/2522)) - To format using `Temporal.ZonedDateTime`'s time zone, use `Temporal.ZonedDateTime.prototype.toLocaleString`. This method: 1. Creates a new `Intl.DateTimeFormat` instance in the same time zone and calendar as the `Temporal.ZonedDateTime` instance 2. Creates a `Temporal.Instant` from the `Temporal.ZonedDateTime` instance. 3. Formats that `Temporal.Instant` instance using the created `Intl.DateTimeFormat` instance. - To format in a time zone that does not match the time zone of the `Temporal.ZonedDateTime` instance: 1. Create a new `Temporal.ZonedDateTime` instance in the right time zone using `Temporal.ZonedDateTime.prototype.withTimeZone`. - To get the current system time zone, use `Temporal.Now.timeZoneId()`. Be careful when caching the current system time zone (or an `Intl.DateTimeFormat` instance using that time zone), because the system time zone can change during the lifetime of your program (e.g. when a user on a mobile device crosses a time zone boundary or when a user manually edits time zone settings). 2. Follow the steps above. - Generally, try to always include the `timeZone` property when creating an `Intl.DateTimeFormat` instance to avoid an ambiguity about which time zone the formatted results will be in. - `Intl.DateTimeFormat` instances can be expensive to create. For performance-sensitive code where the same calendar and time zone are used repeatedly for formatting, we recommend creating and reusing an `Intl.DateTimeFormat` instance with the desired `timeZone` and `calendar` options, and then formatting using the value of `Temporal.ZonedDateTime.prototype.epochMilliseconds`. `Intl.DateTimeFormat` instances may also require a lot of RAM, so indefinitely caching large numbers of them is not recommended for memory-constrained environments. - The `.calendar` property on Temporal types has been replaced with a `.calendarId` property that returns the string calendar identifier and a `.getCalendar()` method that returns an object that implements `Temporal.CalendarProtocol`. - `getCalendar()` will always return a new object if the containing instance was constructed using a built-in calendar identifier string. However, if the containing instance was constructed using a calendar object (either a built-in calendar or custom calendar), then the same object is returned. (\[[`cc701b4`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/cc701b45)], see also [Upstream issue](https://redirect.github.com/tc39/proposal-temporal/issues/1808)) - Temporal will compare calendars by testing for string equality between calendar identifiers. When a calendar is an object, its `id` property will be used for comparison. (\[[`3916e54`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/3916e547)], see also [Upstream issue](https://redirect.github.com/tc39/proposal-temporal/issues/1808)) - The `.calendar` property has been entirely removed from `Temporal.PlainTime`. (\[[`0727d86`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/0727d86e)], see also [Issue 1](https://redirect.github.com/tc39/proposal-temporal/issues/1808), [Issue 2](https://redirect.github.com/tc39/proposal-temporal/issues/1588)) - The `.timeZone` property on `Temporal.ZonedDateTime` has been replaced with a `.timeZoneId` property that returns the string time zone identifier and a `.getTimeZone()` method that returns an object that implements `Temporal.TimeZoneProtocol`. (\[[`d3263f0`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/d3263f0)], see also Upstream issue) - `getTimeZone()` will always return a new object if the `Temporal.ZonedDateTime` instance was constructed using a built-in time zone identifier string. However, if the instance was constructed using a time zone object (either a built-in time zone or custom time zone), then the same object is returned. - `Termporal.Now.timeZone()` is replaced by `Temporal.Now.timeZoneId()`, which returns a time zone identifier string, not a `Temporal.TimeZone` instance. (\[[`600f0cc`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/600f0cc7)], see also [Upstream issue](https://redirect.github.com/tc39/proposal-temporal/issues/1808)) - Temporal will compare time zones by testing for string equality between calendar identifiers. When a calendar is an object, its `id` property will be used for comparison. (\[[`d6cb286`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/d6cb2862)], see also [Upstream issue](https://redirect.github.com/tc39/proposal-temporal/issues/1808)) - Require the `id` property and make overriding `toString` optional (but recommended!) for `Temporal.TimeZoneProtocol`. (\[[`97637bb`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/97637bbc)]) - Remove support for nested time zone and calendar property bags. (\[[`9b7f61a`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/9b7f61ae)], \[[`0c38267`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/0c38267b)], see also [Discussion](https://redirect.github.com/tc39/proposal-temporal/issues/2104#issuecomment-140)) - Require the remainder returned by the `NanosecondsToDays` internal operation to be less than the length of one calendar day. This could happen due to shenanigans in a custom time zone's `getOffsetNanosecondsFor` or `getPossibleInstantsFor` methods, or a custom calendar's `dateAdd` method. (\[[`44b00a3`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/44b00a38)], see also [Upstream issue](https://redirect.github.com/tc39/proposal-temporal/issues/2357) - Set an upper limit of 1e9 on rounding increments. (\[[`5d78c81`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/5d78c815)]) - Require `fields` and `mergeFields` methods for `Temporal.CalendarProtocol` (custom calendar) objects. (\[[`5ad6327`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/5ad63274)]) - Reject Z designators when parsing `Temporal.PlainTime` strings. Bug fixes: - Read field identifiers from a calendar's `fields()` method during `dateFromFields()`, `yearMonthFromFields()`, and `monthDayFromFields()`. Previously, these methods only referenced hardcoded `'era'` and `'eraYear'` field identifiers. (\[[`375a4ad`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/375a4ad9)]) - Avoid precision loss in AddDuration operations. (\[[`c0f7349`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/c0f7349a)]) - Fix an infinite-loop bug and a RangeError during non-ISO calendar calculations. (\[[`d94c1cd`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/d94c1cd9)], see also [proposal-temporal PR](https://redirect.github.com/tc39/proposal-temporal/pull/2539), [Issue 1](https://redirect.github.com/tc39/proposal-temporal/issues/2383), [Issue 2](https://redirect.github.com/tc39/proposal-temporal/issues/2537)) - Avoid rounding errors in `BalanceTime` operations. (\[[`9260a8a`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/9260a8a0)]) - Avoid precision loss in `NanosecondsToDays` operations. (\[[`e02f062`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/e02f0626)]) - Require that results from `NanosecondsToDays` calls don't flip sign. (\[[`0b238cc`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/0b238ccf)]) - Fix bugs introduced while restricting the creation of `Temporal.Duration` using non-numeric inputs. (\[[`46c4132`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/46c4132d)], see also [Upstream issue](https://redirect.github.com/tc39/proposal-temporal/issues/2112)) - Fix bugs when passing fractional numbers to `CreateTemporalDuration`. (\[[`856a546`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/856a5460)], see also [Upstream issue](https://redirect.github.com/tc39/proposal-temporal/issues/2246)) - Always return a Number of nanoseconds from `RoundDuration`. (\[[`8d3c1f1`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/8d3c1f1b)]) - Use BigInt math in `RoundDuration` to avoid problems when the values are larger than `Number.MAX_SAFE_INTEGER`. (\[[`955323f`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/955323f8)]) - Always start at the end of 1972 when computing a `Temporal.PlainMonthDay` from fields, preventing the reference year from accidentally being in 1971. (\[[`ef4a0c4`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/ef4a0c4b)]) - Apply the overflow behaviour to year/month/day values in `monthDayFromFields`. (\[[`7ebd0f9`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/7ebd0f96)]) - Preserve the day of month when constraining a nonexistent leap month, instead of defaulting to the end of the closest corresponding regular month. (\[[`996f8fa`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/996f8fa1)]) - Allow month codes `'M01L'` and `'M12L'` in the Chinese calendar. (\[[`696f2c7`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/696f2c7e)]) - Avoid overflows in `GetNamedTimeZoneOffsetNanoseconds`. (\[[`c42570b`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/c42570b8)]) - Fix calendar validation in various ToTemporal\_\_\_ operations. (\[[`e391397`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/e3913974)], see also [Upstream issue](https://redirect.github.com/tc39/proposal-temporal/issues/2546)) - Don't call `GetMethod` on a string calendar. (\[[`fe698d8`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/fe698d8d)], see also [Upstream issue](https://redirect.github.com/tc39/proposal-temporal/pull/2547)) - Avoid rounding errors in `BalanceDurationRelative` and `UnbalanceDurationRelative`. (\[[`a907acf`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/a907acf0)]) - Check for negative day length in `Temporal.ZonedDateTime.prototype.round`. (\[[`0d2d60e`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/0d2d60ec)], see also [Spec PR](https://redirect.github.com/tc39/proposal-temporal/pull/2261)) This change avoids a common bug where a UTC timestamp is accidentally interpreted as if it were a local time in a real time zone. If you do want to parse the time portion of a UTC timestamp string, use: `Temporal.Instant.from(s).toZonedDateTimeISO('UTC').toPlainTime()`. (\[[`a7a50ea`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/a7a50eac)]) - Reject 0-value components when parsing `Temporal.Duration` strings, and avoid rounding errors when nanoseconds components are present. (\[[`58b5601`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/58b5601a)]) - Reject `relativeTo` string options that are neither valid `Temporal.PlainDate` nor `Temporal.ZonedDateTime` strings, such as `'2022-08-18T17:01Z'`. (\[[`4db15c4`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/4db15c41)]) - Add validation for the return values from calendar operations. (\[[`d88cfa4`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/d88cfa4d)]) - Validate required methods of `Temporal.TimeZoneProtocol` and `Temporal.CalendarProtocol`. (\[[`84563ce`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/84563cea)], \[[`755c762`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/755c7620)], see also [Discussion](https://redirect.github.com/tc39/proposal-temporal/issues/2104#issuecomment-140)) - Throw earlier when users might mix up positional `Temporal.TimeZone` and `Temporal.Calendar` arguments with each other, to prevent bugs like `new Temporal.ZonedDateTime(0n, cal, tz)` where the switched calendar and time zone arguments would cause exceptions to be thrown later. (\[[`7922f1f`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/7922f1f9)]) Non-breaking changes: - Implement `yearOfWeek` methods that complement existing `weekOfYear` methods. The new method returns the year associated with `weekOfYear`, which may (see https://en.wikipedia.org/wiki/ISO_week_date) vary from `year` in some calendars like `'iso8601'`. This new method can be useful for formatting IS0 8601 strings using the year-week-day format like `1981-W53-7`. (\[[`bf08ca5`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/bf08ca56)]) - Support new Internet Extended Date-Time (IXDTF) Annotations - See the [Temporal + IXDTF tracking issue](https://redirect.github.com/tc39/proposal-temporal/issues/1450). - Align ISO 8601 grammar with annotations from IXDTF specification. Calendar and time zone annotations are now allowed to contain a "critical" flag (`'!'`) prefix. Critical flags have no effect when parsing input strings because Temporal already treats unknown or inconsistent inputs as errors by default. (\[[`e8b2e71`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/e8b2e71c)]) - There can be multiple types of annotations in an IXDTF string. Temporal only recognizes time zone and calendar annotations. Unrecognized non-critical annotations will be ignored. Unrecognized critical annotations will cause the parsing method to throw an exception. - Allow `toString()` methods for `Temporal.PlainDate`, `Temporal.PlainDateTime`, `Temporal.PlainYearMonth`, `Temporal.PlainMonthDay`, and `Temporal.ZonedDateTime` to emit critical IXDTF annotations using the `'critical'` option. Use this option with care, because the platform that you're communicating with may not understand this syntax. `calendarName: 'critical'` behaves like `calendarName: 'always'` and `timeZoneName: 'critical'` behaves like `timeZoneName: 'always'`, but they also output a `'!'` prefix in the corresponding annotation. (\[[`50a64f1`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/50a64f16)]) Critical flags are never used by Temporal, but could be consumed by other programs. - Ignore calendar annotations when parsing `Temporal.Instant` strings. (\[[`b86b87f`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/b86b87f0)]) - Allow calendar and/or time zone annotations after strings without a time part: YYYY-MM-DD, YYYY-MM, and MM-DD. (\[[`acd6464`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/acd6464f)]) - Disallow UTC offsets in YYYY-MM and MM-DD strings because they could cause ambiguity between an offset and the day of a YYYY-MM-DD string. (\[[`acd6464`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/acd6464f)]) - Reject ambiguous time strings even with calendar annotations. (\[[`af87527`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/af875275)]) - Implement the full set of rounding modes. New modes include `'expand'`, `'halfCeil'`, `'halfFloor'`, `'halfTrunc'`, and `'halfEven'`. (\[[`eb5404d`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/eb5404d1)]) - Treat calendar names as case-insensitive. (\[[`9e730d6`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/9e730d68)]) - Improve cross-binary compatibility of polyfill objects by storing internals on `globalThis`. (\[[`73a0bf3`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/73a0bf36)], see also [GitHub Issue](https://redirect.github.com/js-temporal/temporal-polyfill/issues/164)) - Allow various `Temporal.Calendar` methods to return 0. (\[[`8a49023`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/8a49023b)]) - Improve error messages when converting fields to a `Temporal.PlainMonthDay`. (\[[`e1cd417`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/e1cd4170)]) - Round towards the Big Bang in epoch time getters. (\[[`6d124a5`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/6d124a56)], see also [Upstream issue](https://redirect.github.com/tc39/proposal-temporal/issues/2423), [Spec change](https://redirect.github.com/tc39/proposal-temporal/issues/2424)) - Improve performance when operating on large numbers in `BalanceISODate`. (\[[`d2a23dd`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/d2a23dd5)]) - Optimize `Temporal.TimeZone.prototype.getNextTransition()` for dates that predate 1847, which is the earliest data in the IANA time zone database. (\[[`9591af3`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/9591af3b)]) - Improve performance when out-of-range finding transition points for named time zones. (\[[`3b61abf`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/3b61abfe)]) - Special-case zones with precomputed DST transition points in `GetPreviousTransition`. (\[[`5922bdf`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/5922bdf1)]) Other: - Bump required dependency versions. (\[[`c65455a`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/c65455a5)]) - Fix sourcemaps so they point directly to TS source files. (\[[`6b462d4`](https://redirect.github.com/js-temporal/temporal-polyfill/commit/6b462d49)], see also [GitHub PR](https://redirect.github.com/js-temporal/temporal-polyfill/pull/194))Configuration
📅 Schedule: Branch creation - "every weekend" in timezone Asia/Tokyo, Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.