There will be an extremely similar function that accepts a calendar year
rather than ISO year in a subsequent commit. Rename the ISO year variant
so that they are more distinguishable.
Replace the icu4c-based calendar implementation with one built on the
icu4x Rust crate (icu_calendar).
The icu4c API does not expose the píngqì month-assignment algorithm
used by the Chinese and Dangi lunisolar calendars. Our old code had to
approximate this by walking months via epoch millisecond arithmetic and
manually tracking leap month positions, which produced incorrect month
codes and ordinal month numbers for certain years. The icu4x calendar
crate handles píngqì natively.
With this patch, which is almost a 1-to-1 mapping of ICU invocations, we
pass 100% of all Temporal test262 tests.
The end goal might be to use icu4x for all of our ICU needs. But it does
not yet provide the APIs needed for all ECMA-402 prototypes.
This adds international calendar support to our Temporal implementation,
using the Intl Era and Month Code Proposal as a guide. See:
https://tc39.es/proposal-intl-era-monthcode/
Same as commit f9fa548d43.
These are String from the outset, so this patch is almost entirely just
changing function parameter types. This will allow us to cache calendar
objects in ICU without invoking any extra allocations.
The result of parsing an identifier cannot change. It is not cheap to do
so, so let's cache the result.
This is hammered in a few test262 tests. On my machine, this reduces the
runtime of each test/staging/sm/Date/dst-offset-caching-{N}-of-8.js by
0.3 to 0.5 seconds. For example:
dst-offset-caching-1-of-8.js: Reduces from 1.2s -> 0.9s
dst-offset-caching-3-of-8.js: Reduces from 1.5s -> 1.1s
These are String from the outset, so this patch is almost entirely just
changing function parameter types. This will allow us to cache time zone
parse results without invoking any extra allocations.
This reverts commit 3f75cf270a.
This change was meant to be editorial, but it caused a regression. See:
https://github.com/tc39/proposal-temporal/commit/3ffa677
A separate test was not added here to catch this regression, because it
affects non-ISO-8601 calendars, which we do not yet implement.
I don't fully understand the BigInt math here, as the computation for
d1 and d2 don't align with the spec due to BigInt logic. This was
discussed a bit in SerenityOS's Discord some years ago:
https://discord.com/channels/830522505605283862/851522357734408232/978786665306918932
But some new tests in test262 indicate that we need to handle negative
values here, instead of just throwing away the sign.
This is an editorial change in the Temporal proposal. See:
https://github.com/tc39/proposal-temporal/commit/9110854
This change actually exposed a bug in our validator for month codes
(which is only used by this same function). We would previously allow
"M00" as a month code, which is invalid (it must be "M00L").
This is an editorial change in the Temporal proposal. See:
https://github.com/tc39/proposal-temporal/commit/1fdf09a
Note that the integer limits in the above commit are in spec headers,
which we don't copy to our implementation.
This is an editorial change in the Temporal proposal. See:
https://github.com/tc39/proposal-temporal/commit/96bb9b0
Note that we already had a struct for this, but now that it has a proper
name and spec link, this renames it to match other Parse Records and
places it alongside them.
