-
Notifications
You must be signed in to change notification settings - Fork 153
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Duration.p.round
doesn't balance from hours (or smaller) to weeks (or larger) units
#2508
Comments
Duration.p.round
doesn't balance from hours (or smaller) to weeks (or larger) units
Thanks @lionel-rowe for catching this. Your second result is the correct result. Your first result is unexpected. We'll get this fixed, although if this is a spec bug we'll need to wait to fix it in the polyfills until the spec change is OK-ed at the next TC39 committee meeting in late March. @ptomato If I'm reading the spec correctly, this looks like a bug in the spec that the polyfills are faithfully reproducing. In Here's a simpler repro: Temporal.Duration.from('P100D').round({ relativeTo: '2023-02-21', largestUnit: 'month' })
// P3M11D - correct result
Temporal.Duration.from('PT2400H').round({ relativeTo: '2023-02-21', largestUnit: 'month' })
// P100D - expected P3M11D |
…on.prototype.round If we balance the bigger units before the smaller ones, then we never properly balance the days that are added from balancing units up to day length. Changing the order of operations ensures proper balancing of all units. Closes: tc39#2508
…on.prototype.round If we balance the bigger units before the smaller ones, then we never properly balance the days that are added from balancing units up to day length. Changing the order of operations ensures proper balancing of all units. There is also no more need for the call to MoveRelativeZonedDateTime() in the end of the method, so it's been removed. Closes: tc39#2508
Before the issue is fixed, rounding a duration such as 'PT2400h' with months as largest unit fails to balance it properly and gives a result with days being the largest unit. The test ensures that such rounding happens properly.
Before the issue is fixed, rounding a duration such as 'PT2400h' with months as largest unit fails to balance it properly and gives a result with days being the largest unit. The test ensures that such rounding happens properly.
Before the issue is fixed, rounding a duration such as 'PT2400h' with months as largest unit fails to balance it properly and gives a result with days being the largest unit. The test ensures that such rounding happens properly.
Before the issue is fixed, rounding a duration such as 'PT2400h' with months as largest unit fails to balance it properly and gives a result with days being the largest unit. The test ensures that such rounding happens properly.
…on.prototype.round If we balance the bigger units before the smaller ones, then we never properly balance the days that are added from balancing units up to day length. Changing the order of operations ensures proper balancing of all units. There is also no more need for the call to MoveRelativeZonedDateTime() in the end of the method, so it's been removed. Closes: tc39#2508
…on.prototype.round If we balance the bigger units before the smaller ones, then we never properly balance the days that are added from balancing units up to day length. Changing the order of operations ensures proper balancing of all units. There is also no more need for the call to MoveRelativeZonedDateTime() in the end of the method, so it's been removed. Closes: #2508
…on.prototype.round If we balance the bigger units before the smaller ones, then we never properly balance the days that are added from balancing units up to day length. Changing the order of operations ensures proper balancing of all units. There is also no more need for the call to MoveRelativeZonedDateTime() in the end of the method, so it's been removed. Closes: #2508 UPSTREAM_COMMIT=36746e5ef8da4688237c195e51c8081e3304ab0f
When the time portion of a duration, rounded relative to a ZonedDateTime, would land on a non-24-hour day, we'd get incorrect results. This is a regression from #2508 where although switching the order of BalanceDateDurationRelative and BalanceTimeDurationRelative was correct, we should not have removed the MoveRelativeZonedDateTime call. Closes: #2742
When the time portion of a duration, rounded relative to a ZonedDateTime, would land on a non-24-hour day, we'd get incorrect results. This is a regression from #2508 where although switching the order of BalanceDateDurationRelative and BalanceTimeDurationRelative was correct, we should not have removed the MoveRelativeZonedDateTime call. Closes: #2742
When the time portion of a duration, rounded relative to a ZonedDateTime, would land on a non-24-hour day, we'd get incorrect results. This is a regression from #2508 where although switching the order of BalanceDateDurationRelative and BalanceTimeDurationRelative was correct, we should not have removed the MoveRelativeZonedDateTime call. Closes: #2742
When the time portion of a duration, rounded relative to a ZonedDateTime, would land on a non-24-hour day, we'd get incorrect results. This is a regression from #2508 where although switching the order of BalanceDateDurationRelative and BalanceTimeDurationRelative was correct, we should not have removed the MoveRelativeZonedDateTime call. Closes: #2742
When the time portion of a duration, rounded relative to a ZonedDateTime, would land on a non-24-hour day, we'd get incorrect results. This is a regression from #2508 where although switching the order of BalanceDateDurationRelative and BalanceTimeDurationRelative was correct, we should not have removed the MoveRelativeZonedDateTime call. Closes: #2742
When the time portion of a duration, rounded relative to a ZonedDateTime, would land on a non-24-hour day, we'd get incorrect results. This is a regression from #2508 where although switching the order of BalanceDateDurationRelative and BalanceTimeDurationRelative was correct, we should not have removed the MoveRelativeZonedDateTime call. Closes: #2742
When the time portion of a duration, rounded relative to a ZonedDateTime, would land on a non-24-hour day, we'd get incorrect results. This is a regression from #2508 where although switching the order of BalanceDateDurationRelative and BalanceTimeDurationRelative was correct, we should not have removed the MoveRelativeZonedDateTime call. Closes: #2742
When the time portion of a duration, rounded relative to a ZonedDateTime, would land on a non-24-hour day, we'd get incorrect results. This is a regression from #2508 where although switching the order of BalanceDateDurationRelative and BalanceTimeDurationRelative was correct, we should not have removed the MoveRelativeZonedDateTime call. Closes: #2742
When the time portion of a duration, rounded relative to a ZonedDateTime, would land on a non-24-hour day, we'd get incorrect results. This is a regression from #2508 where although switching the order of BalanceDateDurationRelative and BalanceTimeDurationRelative was correct, we should not have removed the MoveRelativeZonedDateTime call. Closes: #2742
When the time portion of a duration, rounded relative to a ZonedDateTime, would land on a non-24-hour day, we'd get incorrect results. This is a regression from #2508 where although switching the order of BalanceDateDurationRelative and BalanceTimeDurationRelative was correct, we should not have removed the MoveRelativeZonedDateTime call. Closes: #2742
When the time portion of a duration, rounded relative to a ZonedDateTime, would land on a non-24-hour day, we'd get incorrect results. This is a regression from #2508 where although switching the order of BalanceDateDurationRelative and BalanceTimeDurationRelative was correct, we should not have removed the MoveRelativeZonedDateTime call. Closes: #2742
When the time portion of a duration, rounded relative to a ZonedDateTime, would land on a non-24-hour day, we'd get incorrect results. This is a regression from #2508 where although switching the order of BalanceDateDurationRelative and BalanceTimeDurationRelative was correct, we should not have removed the MoveRelativeZonedDateTime call. Closes: #2742
Duration#round
appears to give the wrong answer for certain durations and options. It's also not idempotent — rounding a second time with the same options yields a different result (the originally expected one).Example:
The unexpected behavior affects both:
Surely calling
round
twice with the same options should yield the same result as calling it once? "845 days" is a very unexpected result givenlargestUnit
isyear
.The text was updated successfully, but these errors were encountered: