new Date(-0) has two allowed implementations
# Allen Wirfs-Brock (13 years ago)
sounds reasonable to me. Please file a ticket at bugs.ecmascript.org against the ES6 draft and classify it as a normative change form ES5
# Simon Pieters (13 years ago)
On Tue, 19 Mar 2013 17:12:35 +0100, Allen Wirfs-Brock
<allen at wirfs-brock.com> wrote:
sounds reasonable to me. Please file a ticket at bugs.ecmascript.org
against the ES6 draft and classify it as a normative change form ES5
Done. ecmascript#1357
The spec allows two different behaviors for new Date(-0):
[[ Return an implementation-dependent choice of either ToInteger(time) or ToInteger(time) + (+0). (Adding a positive zero converts −0 to +0.) ]]
jwalden said in #whatwg as to why:
[[ implementation of new Date(-0) has two representations only so that implementations can store dates, internally, as either an int64_t or a double; SpiderMonkey stores internally as double but adds 0 in TimeClip so -0 doesn't have weird behavior; for any implementation using double representation it's easy to look like int64_t, but probably far harder the other way; thus mandating +0 behavior is probably the thing the most people'd be compatible with; I can't think of a good reason to support this difference at the hardware level -- anyone using double representation can do +0 to pretend to be int64_t-represented, and implementations have to have double capabilities to represent math generally, so I don't see why mandating as-if-by-int64_t would be prevented by hardware issues ]] krijnhoetmer.nl/irc-logs/whatwg/20130318#l-708
Could the spec be changed to require -0 to be converted to +0? Doing so would make it easier to write test cases and would remove a possible interop hole that Web pages can fall into (it seems unlikely that they would, but, well, it's the Web we're talking about here).
cheers