https://mail.mozilla.org/pipermail/es-discuss/2013-March/029280.html
On Tue, 19 Mar 2013 17:12:35 +0100, Allen Wirfs-Brock <allen@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
>
>
> On Mar 19, 2013, at 8:05 AM, Simon Pieters wrote:
>
>> Hi
>>
>> 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
>> ]]
>> http://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
fixed in rev15 editor's draft
resolved in rev 15, May 14, 2013 draft