Rebase up to December 2024 #317
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…sets This did not actually lead to any buggy behaviour, as far as I could tell. But it should match the spec text, which parses UTCOffset[~SubMinutePrecision] here. UPSTREAM_COMMIT=c751d1f9890e7cf112e9b1a478141716bca0bf87
This is a follow-up request from Anba, to the normative change in #2925. It moves syntactic validation of month codes and offset strings into PrepareCalendarFields. This allows implementations to store month codes and offset strings as integers in their equivalents of Calendar Fields Records, instead of allocated strings. Closes: #2962 UPSTREAM_COMMIT=fe909ba882ff339042fc33f6b7a0053bb63da553
It is valid to format e.g. a PlainDate with only { era }, or a PlainTime
with only { fractionalSecondDigits }, as those things are part of the data
model.
See: #2795
UPSTREAM_COMMIT=3c56db8269574822010e3bf7e2139d85fd55c69f
Somewhere along the line the spec text got out of sync with the consensus, probably in one of the rebases on newer ECMA-402. When attempting to format a Temporal object, if the DateTimeFormat has options that do not overlap with the data model of the Temporal object, toLocaleString() and format() are supposed to throw a TypeError. Previously, this worked correctly with dateStyle and timeStyle, but not with other options. We would treat the options as if the DateTimeFormat had been created with only default options, which was incorrect. Closes: #2795 UPSTREAM_COMMIT=c982717593a50ed3380f3be1316d37b4616e1cf3
… types timeStyle: 'long' and timeStyle: 'full' include the time zone name for legacy Date formatting. However, PlainTime and PlainDateTime don't include a time zone in their data model, so they shouldn't format a time zone name when using timeStyle. Similarly, PlainYearMonth and PlainMonthDay shouldn't format a day or year respectively when using dateStyle. This was already the consensus but somewhere along the line the spec text got out of sync, probably in a rebase on latest ECMA-402. In the polyfill, we already handled dateStyle for PlainYearMonth and PlainMonthDay. Try to hack around this the same way for timeStyle. Closes: #2795 UPSTREAM_COMMIT=f62aa26bd51d09e2e313e2a9c239c8ad884229d3
UPSTREAM_COMMIT=180a354e874779a989ce0c09e6ffe2b993606943
This was previously not thought necessary, but some month-day combinations are rare enough in the Chinese lunar calendar that they might occur only outside of the representable range. Failing this check would hit an assertion elsewhere anyway, so this is editorial. Closes: #2997 UPSTREAM_COMMIT=e51b82e4f9de4107158e105f1b43559c4134ca48
The enum values are no longer passed anywhere in the spec text, so remove them as a permissible type. Update the polyfill implementation to match, which had a bug; it always assumed ~date~, which was incorrect. Closes: #2999 UPSTREAM_COMMIT=51f61b6a05ce3b0fa6222edec93844d2f36e6bf2
…rder It's easier to inspect at a glance which fields are included when they are given in order. This order is not observable because the list is sorted by lexicographical order anyway before being used to access properties. See: #3001 UPSTREAM_COMMIT=e6660f2ba47361e17e7f34b02a2ac5f404c15478
This pattern is there because of #2729 and #2985. Abstract it into its own operation, for documentation purposes and because it can disappear after tc39/ecma262#1087 is fixed. See: #3005 UPSTREAM_COMMIT=14e85b636a8168aad25447f6a5fed02ef3f8e56f
This operation doesn't exist in the spec text, it's just an optimization to make the tests run faster. See: #3005 UPSTREAM_COMMIT=348c12f6fa96a9886062cbfeda2856a1fe4f91cb
See: #3005 UPSTREAM_COMMIT=848634b69124575ec8c7d826727f130b72befd11
"Normalized" was jargon that we adopted after the February 2023 TC39 meeting. "Internal" is clearer; we convert a Temporal.Duration into an "internal" record for calculations. See: #2953 UPSTREAM_COMMIT=2c9228b6b069a78165db28dbeb56497bb2423016
See: #2953 UPSTREAM_COMMIT=5e95761af087ab4fefe6a73c4de663b6e6eed254
This operation used to do more than just calculate the number of days, and the name used to make more sense when we had BalanceRelative, etc. Now it's just confusing. Rename it to reflect what it does. See: #2953 UPSTREAM_COMMIT=ff968bd80b63faf91c12f3176f98f1f7726aea1c
A normalized time duration is just a number of nanoseconds; we originally planned to convert it to a record with a seconds and subseconds field, but that was never needed. So we don't need to have it be a record in the first place. Rename it to "time duration" (removing "normalized" for the same reason as in the previous commits) and define it as an integer within a certain range. Renames: - all of the NormalizedTimeDuration___ operations to just TimeDuration___ - NormalizeTimeDuration to TimeDurationFromComponents - Internal duration [[NormalizedTime]] field to [[Time]] - "norm" variables to "timeDuration" or "time" if clear from context See: #2953 UPSTREAM_COMMIT=4405f30b4f052cc1efb87464af2dc1b265194218
This previously needed to be a separate operation because you can't just negate a record. Now that time durations are a number, you can negate them, so no need for a subtraction operation when we already have an addition operation. UPSTREAM_COMMIT=36f1baa1dc5595b929b6969314b45a0309661ed5
ptomato
force-pushed
the
rebase
branch
2 times, most recently
from
9000d87 to
ead5626
Compare
justingrant
approved these changes
Mar 22, 2025
| JSBI.BigInt(Call(MapPrototypeGet, NS_PER_TIME_UNIT, [unit]) * increment), | ||
| roundingMode | ||
| ); | ||
| const unitIncrement = JSBI.BigInt(Call(MapPrototypeGet, NS_PER_TIME_UNIT, [unit]) * increment); |
There was a problem hiding this comment.
Minor thing: would it be simpler to read (and slightly smaller bundle?) to use an object literal instead of a Map here? I assume that upstream uses a Map so need to change now, but after we're caught up this might be worth considering.
There was a problem hiding this comment.
Yep, will add this to my list of minor changes post-rebasing.
UPSTREAM_COMMIT=12012602de791e1399a67e9361a90cd3f0de0d44
Brings the reference code in line with the editorial changes in the spec text from the previous commit. UPSTREAM_COMMIT=5cb74c33827442c09ffda2da238774e6cba14424
A test for this was recently added to test262. Per the spec text, Date.prototype.toTemporalInstant should not be contstructible. However, the previous implementation did allow it to be called as a constructor. UPSTREAM_COMMIT=b17d1a8253a83098640a938bdea1b74c64af56d4
(Also includes 4040485c35f966fef0f8eb06fab8190eca72157f squashed in) UPSTREAM_COMMIT=0288bc996e8bb4d7e563ab4e9717479e545e6303
See #3015, which posits that these assertions are hit in existing test262 tests. UPSTREAM_COMMIT=48581b3e34a8f2746850c18e97b49628421ff0bf
These were holdovers from the old terminology. Closes: #3016 UPSTREAM_COMMIT=48634bd8f3ca3fe7d3bd04c7ad1f183ef81310bf
DivideTimeDuration is only called with certain divisors from the table of units, so there's no need for a general-purpose AO. (In the reference code, TimeDuration.prototype.fdiv() is still needed in a few places for implementation reasons having to do with floating-point numbers.) Closes: #3020 UPSTREAM_COMMIT=545776c4f7389f6fbd1f1e98b1bfb734d2695bb7
These are two lingering references to when time durations were a Record with a [[TotalNanoseconds]] field. Closes: #3021 UPSTREAM_COMMIT=6b3ca826668f5d05134e1ba508d0cbfffc22ae5a
Requires adding an expected failure, pending a test262 pull request. UPSTREAM_COMMIT=38346e13e726628f8650a8c23ad9d8d02f6b5ca7
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Second-to-last batch of rebases.