Update to new ComputeNudgeWindow spec text #636
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
Manishearth
force-pushed
the
nudge-window
branch
from
d3594c8 to
9a445cb
Compare
Contributor
Author
|
This now passes tests, but I'm not entirely sure of the impl |
Manishearth
force-pushed
the
nudge-window
branch
from
9a445cb to
6394a10
Compare
Contributor
Author
|
This fails other tests (due to hitting assertions, I think) |
nekevss
reviewed
Nov 27, 2025
Member
nekevss
left a comment
nekevss
left a comment
There was a problem hiding this comment.
Have a couple notes after taking a glance.
Are you still looking into the failures mentioned above?
Contributor
Author
No, but they should be replicable by copying the tests. |
Manishearth
force-pushed
the
nudge-window
branch
from
6394a10 to
acb80b0
Compare
Contributor
Author
|
The failures were due to a missing <=. Fixed. |
Contributor
Author
|
And that fixes the crashes. Would still like to see if this can be written without floats, but I don't have time to do that myself. |
Manishearth
force-pushed
the
nudge-window
branch
from
acb80b0 to
80b79a3
Compare
Contributor
Author
|
Note: I'm not actively working on this right now, and don't really plan to in the near future, if someone wants to figure out how to make the float stuff work. |
Member
|
I have some time and can take a look at this now if you're not currently working on it. |
Contributor
Author
|
That would be great! |
Manishearth
commented
Dec 10, 2025
| // TODO: Add unit tests specifically for nudge_calendar_unit if possible. | ||
| fn nudge_calendar_unit( | ||
|
|
||
| fn nudge_calendar_unit_total( |
Contributor
Author
There was a problem hiding this comment.
nit: mention what spec item this is and why it is different
question: why is this different?
Member
There was a problem hiding this comment.
If you look at the specification, the return of NudgeToCalendarUnit is a record of (NudgeRecord, Total).
The callers of NudgeToCalendarUnit are RoundRelativeDuration and TotalRelativeDuration, the return type of NudgeRecord and Total correspond with the callers, respectively.
This means that for TotalRelativeDuration, the NudgeRecord is being computed and directly discarded; meanwhile, for RoundRelativeDuration, the value of total must be a f64, because the return type of total is a f64.
Ultimately, the changes separate these out into different codepaths, and therefore we are only computing exactly what we need for round and total
Manishearth
commented
Dec 10, 2025
| /// <https://tc39.es/proposal-temporal/#sec-temporal-computenudgewindow> | ||
| /// `compute_nudge_window` in `temporal_rs` refers to step 1-12 of `NudgeToCalendarUnit`. | ||
| /// | ||
| /// For A.O. `ComputeNudgeWinodw`, see `compute_nudge_window_with_shift` |
Contributor
Author
There was a problem hiding this comment.
issue: this is confusing, let's call this compute_and_adjust_nudge_window or something
Member
There was a problem hiding this comment.
That's fair. I can go with that.
Contributor
Author
|
Running this code patched into v8 gives me two (expected) new test successes and one new test failure in |
Member
Shoot, confirmed in Boa too. This looks like it may have something to do with f1c2828. But the curious thing is that that fixed the new precision calculations ... EDIT: Oh, we need to do the full precision calculation. |
Member
|
All tests pass locally on Boa for Duration. |
Contributor
Author
|
Also V8 |
nekevss
approved these changes
Dec 12, 2025
ajperel
pushed a commit
to chromium/chromium
that referenced
this pull request
Dec 16, 2025
Uplift of boa-dev/temporal#647, boa-dev/temporal#636, unicode-org/icu4x#7321 Change-Id: Icf703e2ae907a6a820b6b1141883ed9ab825874c Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7261567 Commit-Queue: Manish Goregaokar <manishearth@google.com> Auto-Submit: Manish Goregaokar <manishearth@google.com> Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org> Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org> Cr-Commit-Position: refs/heads/main@{#1559085}
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Fixes #635
Updates to tc39/proposal-temporal#3172
This passes the test, but it fails other tests. The problem is probably that IncrementRounder isn't written in terms of r1 and r2. @nekevss, I don't understand the full purpose of IncrementRounder being written the way it is: mind having a look?The new spec text changes how r1 and r2 are computed, and they're passed down to IncrementRounder in the spec but not the code, so I assume that IncrementRounder is recomputing them somehow from the inputs.I wrote this to not use IncrementRounder. I'm not 100% sure if the implementation is correct when it comes to how it handles mathematical values.