1050755 - `Date.UTC()` with fewer than two arguments

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Mathias Bynens]

The behavior for `Date.UTC()` is undefined even in the ES6 draft spec. But it would be good to align with other implementations.

Results for:

    [ Date.UTC(), Date.UTC(1) ]

Safari/JavaScriptCore: [ NaN, NaN ]
Chrome/Opera/V8: [ NaN, NaN ]
Safari/JavaScriptCore: [ NaN, NaN ]
Old Opera/Carakan: [ NaN, NaN ]

Only Firefox and IE11 return a non-`NaN` value: [ -2208988800000, -2177452800000 ]

Consider returning `NaN` in such cases to match the majority of other engines.

Comment 1

[Boris Zbarsky [:bzbarsky]]

This is why a spec is needed.

Date.UTC(0) returns the same thing as Date.UTC(undefined) and Date.UTC() in at least Firefox and Chrome.  So this is not just about missing arguments; it's about different behavior after you coerce the argument to a number.

So what is the actual behavior you're asking us to implement?

Comment 2

[Boris Zbarsky [:bzbarsky]]

Oh, I see, fewer than two arguments, ok.

Comment 3

[Mathias Bynens]

(In reply to Boris from comment #1)
> So what is the actual behavior you're asking us to implement?

(In reply to Boris from comment #2)
> Oh, I see, fewer than two arguments, ok.

I don’t actually have a preference – I’d just like all implementations to align. The simplest way to make that happen is to convince Firefox/SpiderMonkey and IE/Chakra to return `NaN` for `Date.UTC` calls with fewer than two arguments, but if everyone else is willing to change, that’s fine too.

The spec bug is here, in case you have a strong opinion: https://bugs.ecmascript.org/show_bug.cgi?id=3112

Comment 4

[Shu-yu Guo [:shu]]

This is now specced, and we should update our implementation: https://tc39.github.io/ecma262/#sec-date.utc

Comment 5

[André Bargull [:anba]]

Attachment: bug1050755.patch

This is covered by test262, so I didn't need to write new tests. \o/

I'll update the patch to use the correct git hash as soon as https://github.com/tc39/ecma262/pull/642 is merged.

Comment 6

[Shu-yu Guo [:shu]]

Comment on attachment 8837575 [details] [diff] [review]
bug1050755.patch

Review of attachment 8837575 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for the patch.

Comment 7

[Tom S]

The pull request has been merged.

Comment 8

[André Bargull [:anba]]

Attachment: bug1050755.patch

Updated patch to apply cleanly on inbound, no functional changes. Carrying r+ from shu.

Comment 9

[André Bargull [:anba]]

(In reply to Tom Schuster [:evilpie] from comment #7)
> The pull request has been merged.

Thanks for pinging bterlson to merge the PR!

Comment 10

[André Bargull [:anba]]

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=98e20233106bdb669ea02ca4cf6745faa48c6e94

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/4db4dc2a4620
Allow to call Date.UTC with fewer than two arguments per ES2017. r=shu

Comment 12

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/4db4dc2a4620

Comment 13

[Florian Scholz (Open Web Docs)]

https://developer.mozilla.org/en-US/Firefox/Releases/54#JavaScript
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/UTC#Compatibility_notes

Comment 14

[Diego Casorran [:diegocr]]

To whom it may concern, i wanted to use this bug to implement feature-detection for Firefox 54+, but it does not seems reliable as the correct behavior is observed under Firefox 52

I.e.

> [ Date.UTC(), Date.UTC(1) ]
< Array [ NaN, NaN ]
>
> navigator.userAgent
< "Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0"

So, the MDN's compatibility notes are not correct - as it does states // Firefox <54: non-NaN - and should be amended, thanks :)