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

Date.UTC(x) [single-argument case] semantics update #1665

Closed
dilijev opened this issue Sep 29, 2016 · 3 comments
Closed

Date.UTC(x) [single-argument case] semantics update #1665

dilijev opened this issue Sep 29, 2016 · 3 comments
Assignees

Comments

@dilijev
Copy link
Contributor

dilijev commented Sep 29, 2016

Behavior implemented in #1333 is that Date.UTC(x) and Date.UTC() where typeof x === number returns NaN.

Spec semantics will be updated (see tc39/ecma262#642) so that Date.UTC() returns NaN and Date.UTC(2017) === Date.UTC(2017, 0).

  • 0-argument case works according to spec.
  • 1-argument case needs to be updated.

See:
tc39/ecma262#642
#1318 (issue)
#1333 (PR)

/cc @bterlson

@dilijev dilijev self-assigned this Sep 29, 2016
@bterlson
Copy link
Contributor

I think it's the reverse isn't it? Date.UTC() currently returns Date.UTC(0, 0, ...) and should return NaN. Date.UTC(2017) currently returns the right thing.

@dilijev
Copy link
Contributor Author

dilijev commented Sep 30, 2016

The patch I previously submitted made it so Date.UTC() and Date.UTC(2017) would both return NaN.
It's possible I misspoke above anyway, so let's just make it explicit with tests:

assert(isNaN(Date.UTC()), "expected: Date.UTC() is NaN");
assert(!isNaN(Date.UTC(2017)), "expected: Date.UTC(2017) is not NaN");
assert(!isNaN(Date.UTC(2017, 0)), "expected: Date.UTC(2017, 0) is not NaN;");
assert(!isNaN(Date.UTC(2017, 0, 1)), "expected: Date.UTC(2017, 0, 1) is not NaN;");
assert(isNaN(Date.UTC(2017, undefined)), "expected: Date.UTC(2017, undefined) is NaN");
assert(Date.UTC(2017) === Date.UTC(2017, 0), "expected: Date.UTC(2017) === Date.UTC(2017, 0)");
assert(Date.UTC(2017, 0) === Date.UTC(2017, 0, 1), "expected: Date.UTC(2017, 0) === Date.UTC(2017, 0, 1)");

Current behavior:

PASS
FAIL: expected: Date.UTC(2017) is not NaN
PASS
PASS
PASS
FAIL: expected: Date.UTC(2017) === Date.UTC(2017, 0)
PASS

Expected behavior:
all PASS

@bterlson
Copy link
Contributor

Yes ok sorry. Seems good, thank you!

dilijev added a commit to dilijev/ChakraCore that referenced this issue Sep 30, 2016
dilijev added a commit to dilijev/ChakraCore that referenced this issue Sep 30, 2016
chakrabot pushed a commit that referenced this issue Oct 3, 2016
…nt. Fixes #1665.

Merge pull request #1672 from dilijev:dateutc

Fixes #1665: Date.UTC(x) [one-argument] spec change.
chakrabot pushed a commit that referenced this issue Mar 16, 2018
…ime value

Merge pull request #4615 from xiaoyinl:dateUTCoverflow

According to spec [Section 20.3.3.4](https://tc39.github.io/ecma262/#sec-date.utc), if the time value is larger than `ktvMax` or smaller than `ktvMin`, then `Date.UTC` should return `NaN` rather than return the actual value.

Also updated the link at L1645 to #1665: "Date.UTC(x) [single-argument case] semantics update".

Test case:
`Date.UTC(2001, 1, 5e+9)`
ChakraCore: 432000980899200000
SpiderMonkey and v8: NaN
chakrabot pushed a commit to nodejs/node-chakracore that referenced this issue Mar 16, 2018
[MERGE #4615 @xiaoyinl] Date.UTC should return NaN for out-of-range time value

Merge pull request #4615 from xiaoyinl:dateUTCoverflow

According to spec [Section 20.3.3.4](https://tc39.github.io/ecma262/#sec-date.utc), if the time value is larger than `ktvMax` or smaller than `ktvMin`, then `Date.UTC` should return `NaN` rather than return the actual value.

Also updated the link at L1645 to chakra-core/ChakraCore#1665:

Reviewed-By: chakrabot <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants