Update dependency @js-temporal/polyfill to v0.4.4

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
@js-temporal/polyfill	0.4.3 -> 0.4.4

---

Release Notes

js-temporal/temporal-polyfill (@​js-temporal/polyfill)

v0.4.4

Compare Source

Breaking changes:

• Temporal.ZonedDateTime objects are no longer supported as parameters to Intl.DateTimeFormat formatting methods. ([12071fb], see also Upstream PR, Upstream PR 2)
  • 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], see also Upstream issue)
  • 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], see also Upstream issue)
  • The .calendar property has been entirely removed from Temporal.PlainTime. ([0727d86], see also Issue 1, Issue 2)
• 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], 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], see also Upstream issue)
  • 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], see also Upstream issue)
• Require the id property and make overriding toString optional (but recommended!) for Temporal.TimeZoneProtocol. ([97637bb])
• Remove support for nested time zone and calendar property bags. ([9b7f61a], [0c38267], see also Discussion)
• 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], see also Upstream issue
• Set an upper limit of 1e9 on rounding increments. ([5d78c81])
• Require fields and mergeFields methods for Temporal.CalendarProtocol (custom calendar) objects. ([5ad6327])
• 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])
• Avoid precision loss in AddDuration operations. ([c0f7349])
• Fix an infinite-loop bug and a RangeError during non-ISO calendar calculations. ([d94c1cd], see also proposal-temporal PR, Issue 1, Issue 2)
• Avoid rounding errors in BalanceTime operations. ([9260a8a])
• Avoid precision loss in NanosecondsToDays operations. ([e02f062])
• Require that results from NanosecondsToDays calls don't flip sign. ([0b238cc])
• Fix bugs introduced while restricting the creation of Temporal.Duration using non-numeric inputs. ([46c4132], see also Upstream issue)
• Fix bugs when passing fractional numbers to CreateTemporalDuration. ([856a546], see also Upstream issue)
• Always return a Number of nanoseconds from RoundDuration. ([8d3c1f1])
• Use BigInt math in RoundDuration to avoid problems when the values are larger than Number.MAX_SAFE_INTEGER. ([955323f])
• Always start at the end of 1972 when computing a Temporal.PlainMonthDay from fields, preventing the reference year from accidentally being in 1971. ([ef4a0c4])
• Apply the overflow behaviour to year/month/day values in monthDayFromFields. ([7ebd0f9])
• Preserve the day of month when constraining a nonexistent leap month, instead of defaulting to the end of the closest corresponding regular month. ([996f8fa])
• Allow month codes 'M01L' and 'M12L' in the Chinese calendar. ([696f2c7])
• Avoid overflows in GetNamedTimeZoneOffsetNanoseconds. ([c42570b])
• Fix calendar validation in various ToTemporal___ operations. ([e391397], see also Upstream issue)
• Don't call GetMethod on a string calendar. ([fe698d8], see also Upstream issue)
• Avoid rounding errors in BalanceDurationRelative and UnbalanceDurationRelative. ([a907acf])
• Check for negative day length in Temporal.ZonedDateTime.prototype.round. ([0d2d60e], see also Spec PR)
  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])
• Reject 0-value components when parsing Temporal.Duration strings, and avoid rounding errors when nanoseconds components are present. ([58b5601])
• Reject relativeTo string options that are neither valid Temporal.PlainDate nor Temporal.ZonedDateTime strings, such as '2022-08-18T17:01Z'. ([4db15c4])
• Add validation for the return values from calendar operations. ([d88cfa4])
• Validate required methods of Temporal.TimeZoneProtocol and Temporal.CalendarProtocol. ([84563ce], [755c762], see also Discussion)
• 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])

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])
• Support new Internet Extended Date-Time (IXDTF) Annotations
  • See the Temporal + IXDTF tracking issue.
  • 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])
    • 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])
    Critical flags are never used by Temporal, but could be consumed by other programs.
  • Ignore calendar annotations when parsing Temporal.Instant strings. ([b86b87f])
  • Allow calendar and/or time zone annotations after strings without a time part: YYYY-MM-DD, YYYY-MM, and MM-DD. ([acd6464])
  • 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])
  • Reject ambiguous time strings even with calendar annotations. ([af87527])
• Implement the full set of rounding modes.
  New modes include 'expand', 'halfCeil', 'halfFloor', 'halfTrunc', and 'halfEven'.
  ([eb5404d])
• Treat calendar names as case-insensitive. ([9e730d6])
• Improve cross-binary compatibility of polyfill objects by storing internals on globalThis. ([73a0bf3], see also GitHub Issue)
• Allow various Temporal.Calendar methods to return 0. ([8a49023])
• Improve error messages when converting fields to a Temporal.PlainMonthDay. ([e1cd417])
• Round towards the Big Bang in epoch time getters. ([6d124a5], see also Upstream issue, Spec change)
• Improve performance when operating on large numbers in BalanceISODate. ([d2a23dd])
• Optimize Temporal.TimeZone.prototype.getNextTransition() for dates that predate 1847, which is the earliest data in the IANA time zone database. ([9591af3])
• Improve performance when out-of-range finding transition points for named time zones. ([3b61abf])
• Special-case zones with precomputed DST transition points in GetPreviousTransition. ([5922bdf])

Other:

• Bump required dependency versions. ([c65455a])
• Fix sourcemaps so they point directly to TS source files. ([6b462d4], see also GitHub PR)

---

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 was generated by Mend Renovate. View the repository job log.