Skip to content
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: Change offset in ISODateTimeWithinLimits to actually 24h #1723

Merged
merged 1 commit into from
Aug 31, 2021

Conversation

linusg
Copy link
Member

@linusg linusg commented Aug 13, 2021

The note (and the algorithm itself) claims:

time within 24 hours (8.64 × 10^16 nanoseconds)

This is incorrect, 24 hours are 8.64 × 10^13 nanoseconds, which is the
value that was intended to be used here (it's already correctly used in
other places). 8.64 × 10^16 nanoseconds are actually 24000 hours.

The note (and the algorithm itself) claims:

> time within 24 hours (8.64 × 10^16 nanoseconds)

This is incorrect, 24 hours are 8.64 × 10^13 nanoseconds, which is the
value that was intended to be used here (it's already correctly used in
other places). 8.64 × 10^16 nanoseconds are actually 24000 hours.
@codecov
Copy link

codecov bot commented Aug 13, 2021

Codecov Report

Merging #1723 (2c2ec00) into main (a9742c7) will decrease coverage by 22.13%.
The diff coverage is n/a.

❗ Current head 2c2ec00 differs from pull request most recent head 3c62687. Consider uploading reports for the commit 3c62687 to get more accurate results
Impacted file tree graph

@@             Coverage Diff             @@
##             main    #1723       +/-   ##
===========================================
- Coverage   95.03%   72.89%   -22.14%     
===========================================
  Files          19       18        -1     
  Lines       10785     4840     -5945     
  Branches     1725     1058      -667     
===========================================
- Hits        10249     3528     -6721     
- Misses        523     1030      +507     
- Partials       13      282      +269     
Flag Coverage Δ
test262 72.89% <ø> (ø)
tests ?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
polyfill/lib/calendar.mjs 23.22% <0.00%> (-71.15%) ⬇️
polyfill/lib/intl.mjs 67.46% <0.00%> (-32.54%) ⬇️
polyfill/lib/instant.mjs 79.13% <0.00%> (-15.31%) ⬇️
polyfill/lib/plainmonthday.mjs 79.01% <0.00%> (-14.14%) ⬇️
polyfill/lib/plainyearmonth.mjs 83.42% <0.00%> (-12.99%) ⬇️
polyfill/lib/ecmascript.mjs 82.79% <0.00%> (-12.28%) ⬇️
polyfill/lib/plaindatetime.mjs 85.14% <0.00%> (-12.17%) ⬇️
polyfill/lib/timezone.mjs 81.66% <0.00%> (-11.80%) ⬇️
polyfill/lib/zoneddatetime.mjs 89.41% <0.00%> (-8.99%) ⬇️
polyfill/lib/duration.mjs 90.38% <0.00%> (-7.70%) ⬇️
... and 7 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a9742c7...3c62687. Read the comment docs.

@linusg
Copy link
Member Author

linusg commented Aug 13, 2021

It should be noted that the polyfill implements this differently and is not affected by this change AFAICT.

CreateTemporalDate: (isoYear, isoMonth, isoDay, calendar = ES.GetISO8601Calendar()) => {
const TemporalPlainDate = GetIntrinsic('%Temporal.PlainDate%');
const result = ObjectCreate(TemporalPlainDate.prototype);
ES.CreateTemporalDateSlots(result, isoYear, isoMonth, isoDay, calendar);
return result;
},
CreateTemporalDateTimeSlots: (result, isoYear, isoMonth, isoDay, h, min, s, ms, µs, ns, calendar) => {
ES.RejectDateTime(isoYear, isoMonth, isoDay, h, min, s, ms, µs, ns);
ES.RejectDateTimeRange(isoYear, isoMonth, isoDay, h, min, s, ms, µs, ns);

RejectDateTimeRange: (year, month, day, hour, minute, second, millisecond, microsecond, nanosecond) => {
ES.RejectToRange(year, YEAR_MIN, YEAR_MAX);
// Reject any DateTime 24 hours or more outside the Instant range
if (
(year === YEAR_MIN &&
null ==
ES.GetEpochFromISOParts(
year,
month,
day + 1,
hour,
minute,
second,
millisecond,
microsecond,
nanosecond - 1
)) ||
(year === YEAR_MAX &&
null ==
ES.GetEpochFromISOParts(year, month, day - 1, hour, minute, second, millisecond, microsecond, nanosecond + 1))
) {
throw new RangeError('DateTime outside of supported range');
}
},

@linusg
Copy link
Member Author

linusg commented Aug 13, 2021

This is also mentioned in #1502.

Copy link
Collaborator

@ptomato ptomato left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. I don't think this needs extra tests as it is already sufficiently covered that anyone implementing it as written would fail the tests already.

I will mark this as draft so that it's not accidentally merged before being presented for consensus.

@ptomato ptomato marked this pull request as draft August 13, 2021 18:52
@ptomato ptomato marked this pull request as ready for review August 31, 2021 19:24
@ptomato
Copy link
Collaborator

ptomato commented Aug 31, 2021

This change achieved consensus in TC39.

@ptomato ptomato merged commit 1d61d6f into tc39:main Aug 31, 2021
@linusg linusg deleted the fix-limit-in-isodatetimewithinlimits branch October 23, 2021 09:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants