-
Notifications
You must be signed in to change notification settings - Fork 149
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
Normative: Upper limit on rounding increments #2480
Conversation
Codecov Report
@@ Coverage Diff @@
## main #2480 +/- ##
==========================================
- Coverage 94.97% 94.95% -0.02%
==========================================
Files 20 20
Lines 10903 10825 -78
Branches 1996 1959 -37
==========================================
- Hits 10355 10279 -76
Misses 487 487
+ Partials 61 59 -2
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
Previously in a few cases (calendar units in Duration) the value for the roundingIncrement option had no upper limit, other than having to be finite. These tests cover a normative change limiting it to 1e9. Normative PR: tc39/proposal-temporal#2480
1. If _increment_ < *1*<sub>𝔽</sub>, throw a *RangeError* exception. | ||
1. Return truncate(ℝ(_increment_)). | ||
1. Let _integerIncrement_ be truncate(ℝ(_increment_)). | ||
1. If _integerIncrement_ < 1 or _integerIncrement_ > 10<sup>9</sup>, throw a *RangeError* exception. | ||
1. Return _integerIncrement_. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gibson042 I thought you might be particularly interested to note this change since you did an earlier similar change to check the range for fractionalSecondDigits
after truncating it; now that we have an upper limit, it matters here too.
Tests for this are in tc39/test262#3770 |
Rounding increments are usually limited. In a few cases (years, months, weeks, and days for Temporal.Durations), they were previously only limited by being required to be finite. This introduces a limit of 1e9 for these previously unlimited cases. 1e9 fits in a 32-bit integer, to make things simpler for implementations, but is clearer to explain in end-user documentation than UINT32_MAX.
Previously in a few cases (calendar units in Duration) the value for the roundingIncrement option had no upper limit, other than having to be finite. These tests cover a normative change limiting it to 1e9. Normative PR: tc39/proposal-temporal#2480
Previously in a few cases (calendar units in Duration) the value for the roundingIncrement option had no upper limit, other than having to be finite. These tests cover a normative change limiting it to 1e9. Normative PR: tc39/proposal-temporal#2480
2e091af
to
2728067
Compare
This change reached consensus at the 2023-01-31 TC39 plenary meeting. Test262 tests have already been merged. |
Rounding increments are usually limited. In a few cases (years, months, weeks, and days for Temporal.Durations), they were previously only limited by being required to be finite. This introduces a limit of 1e9 for these previously unlimited cases.
1e9 fits in a 32-bit integer, to make things simpler for implementations, but is clearer to explain in end-user documentation than UINT32_MAX.
Closes: #2458