Closed Bug 1050755 Opened 10 years ago Closed 7 years ago

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

Categories

(Core :: JavaScript Engine, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla54
Tracking Status
firefox54 --- fixed

People

(Reporter: mathias, Assigned: anba)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-complete)

Attachments

(1 file, 1 obsolete file)

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.
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?
Flags: needinfo?(mathias)
Oh, I see, fewer than two arguments, ok.
Flags: needinfo?(mathias)
(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
This is now specced, and we should update our implementation: https://tc39.github.io/ecma262/#sec-date.utc
Blocks: test262
Assignee: nobody → andrebargull
Status: NEW → ASSIGNED
Attached patch bug1050755.patch (obsolete) — Splinter Review
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.
Attachment #8837575 - Flags: review?(shu)
Comment on attachment 8837575 [details] [diff] [review]
bug1050755.patch

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

Thanks for the patch.
Attachment #8837575 - Flags: review?(shu) → review+
The pull request has been merged.
Attached patch bug1050755.patchSplinter Review
Updated patch to apply cleanly on inbound, no functional changes. Carrying r+ from shu.
Attachment #8837575 - Attachment is obsolete: true
Attachment #8841722 - Flags: review+
(In reply to Tom Schuster [:evilpie] from comment #7)
> The pull request has been merged.

Thanks for pinging bterlson to merge the PR!
Pushed by cbook@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/4db4dc2a4620
Allow to call Date.UTC with fewer than two arguments per ES2017. r=shu
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/4db4dc2a4620
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54

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 :)

You need to log in before you can comment on or make changes to this bug.