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: Reject invalid output from custom Calendar/TimeZone methods #2456

Merged

Conversation

gibson042
Copy link
Collaborator

@gibson042 gibson042 commented Jan 5, 2023

Fixes #2443

It looked to me like the TimeZone operations already behaved appropriately1, but please verify in review (along with confirmation that I have preserved the distinction between fields that must be positive vs. those that can be zero or negative).

test262 pull request: tc39/test262#3761

Footnotes

  1. GetOffsetNanosecondsFor requires getOffsetNanosecondsFor to return an integral Number with absolute value no greater than nsPerDay, and GetPossibleInstantsFor requires getPossibleInstantsFor to return an iterable of Temporal Instant instances.

@gibson042 gibson042 added behavior Relating to behavior defined in the proposal spec-text Specification text involved calendar Part of the effort for Temporal Calendar API labels Jan 5, 2023
@gibson042 gibson042 requested a review from ptomato January 5, 2023 21:56
@codecov
Copy link

codecov bot commented Jan 5, 2023

Codecov Report

Merging #2456 (8866c51) into main (d05a18b) will decrease coverage by 0.30%.
The diff coverage is 69.30%.

❗ Current head 8866c51 differs from pull request most recent head a8bc580. Consider uploading reports for the commit a8bc580 to get more accurate results

@@            Coverage Diff             @@
##             main    #2456      +/-   ##
==========================================
- Coverage   94.94%   94.64%   -0.30%     
==========================================
  Files          20       20              
  Lines       10821    10971     +150     
  Branches     1957     1987      +30     
==========================================
+ Hits        10274    10384     +110     
- Misses        487      528      +41     
+ Partials       60       59       -1     
Impacted Files Coverage Δ
polyfill/lib/ecmascript.mjs 97.59% <69.30%> (-0.71%) ⬇️
polyfill/lib/intl.mjs 97.82% <0.00%> (-1.98%) ⬇️
polyfill/lib/plainmonthday.mjs 95.71% <0.00%> (-1.97%) ⬇️
polyfill/lib/plainyearmonth.mjs 96.92% <0.00%> (-1.45%) ⬇️
polyfill/lib/plaindate.mjs 98.71% <0.00%> (-0.96%) ⬇️
polyfill/lib/plaindatetime.mjs 97.92% <0.00%> (+0.68%) ⬆️
polyfill/lib/duration.mjs 97.51% <0.00%> (+1.47%) ⬆️
polyfill/lib/plaintime.mjs 100.00% <0.00%> (+1.73%) ⬆️
polyfill/runtest262.mjs 100.00% <0.00%> (+10.00%) ⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

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.

Some minor comments but generally 👍, thanks for doing this!

@@ -157,8 +157,9 @@ <h1>
</dl>
<emu-alg>
1. Let _result_ be ? Invoke(_calendar_, *"year"*, « _dateLike_ »).
1. If _result_ is *undefined*, throw a *RangeError* exception.
1. Return ? ToIntegerWithTruncation(_result_).
1. If Type(_result_) is not Number, throw a *TypeError* exception.
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think the currently preferred phrasing in ECMA-262 is "If result is not a Number, ..." (here and elsewhere)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It is, but this preserves internal consistency in the proposal.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I have a slight preference for having new sections follow the new conventions over internal consistency (less work for me later), but I don't feel strongly about it; it's fine to leave it like this.

Comment on lines +161 to +211
1. If IsIntegralNumber(_result_) is *false*, throw a *RangeError* exception.
1. Return ℝ(_result_).
Copy link
Collaborator

Choose a reason for hiding this comment

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

I guess this is a matter of preference, but once we've established it's a Number, you could use "Return ? ToIntegerIfIntegral(result)" here. (Although maybe it's better not to do that since there isn't a convenient ToIntegerIfPositiveAndIntegral operation to call in the positive-integer ones)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Right, this implements structural similarity across the operations (but I have no objections to the alternative).

spec/calendar.html Outdated Show resolved Hide resolved
@@ -193,8 +197,8 @@ <h1>
</dl>
<emu-alg>
1. Let _result_ be ? Invoke(_calendar_, *"monthCode"*, « _dateLike_ »).
1. If _result_ is *undefined*, throw a *RangeError* exception.
1. Return ? ToString(_result_).
1. If Type(_result_) is not String, throw a *TypeError* exception.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Similarly, "If result is not a String, ..." (here and elsewhere)

@@ -373,7 +402,8 @@ <h1>
</dl>
<emu-alg>
1. Let _result_ be ? Invoke(_calendar_, *"inLeapYear"*, « _dateLike_ »).
1. Return ToBoolean(_result_).
1. If Type(_result_) is not Boolean, throw a *TypeError* exception.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Similarly, "If result is not a Boolean, ..."

spec/intl.html Outdated Show resolved Hide resolved
polyfill/lib/ecmascript.mjs Outdated Show resolved Hide resolved
polyfill/lib/ecmascript.mjs Outdated Show resolved Hide resolved
polyfill/lib/ecmascript.mjs Outdated Show resolved Hide resolved
@ptomato ptomato marked this pull request as draft January 6, 2023 19:04
@ptomato
Copy link
Collaborator

ptomato commented Jan 6, 2023

Draft because it needs to be presented to TC39.

@ptomato ptomato marked this pull request as ready for review February 1, 2023 01:18
@ptomato ptomato force-pushed the gh-2443-reject-invalid-custom-method-output branch from 8866c51 to a8bc580 Compare February 1, 2023 01:38
@ptomato ptomato merged commit 189e689 into tc39:main Feb 1, 2023
@ptomato
Copy link
Collaborator

ptomato commented Feb 1, 2023

This achieved consensus in the 2023-01-31 TC39 plenary meeting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
behavior Relating to behavior defined in the proposal calendar Part of the effort for Temporal Calendar API spec-text Specification text involved
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Is it appropriate to modify values returned from invoking calendar methods?
2 participants