js.Date functions can return NaN, so they should be typed as Double

[sjrd]

Was: On Firefox, (some) js.Date functions can return -0, which cause CCEs

Reproducible with testSuite/testHtmlFastOpt with Firefox. Also:

    import js.DynamicImplicits._

    val utc = java.util.Date.UTC(0, 0, 0, 0, 0, 0)
    val date = new js.Date(utc)

    println("getUTCDate = " + date.getUTCDate())
    println("getUTCMonth = " + date.getUTCMonth())
    println("getUTCFullYear = " + date.getUTCFullYear())

    val dyndate = date.asInstanceOf[js.Dynamic]
    val h = dyndate.getUTCHours()
    println(js.typeOf(h))
    println(h)
    println(1.0 / h)

    println("getUTCHours = " + date.getUTCHours())
    println("getUTCMinutes = " + date.getUTCMinutes())
    println("getUTCSeconds = " + date.getUTCSeconds())

gives:

getUTCDate = 31
getUTCMonth = 11
getUTCFullYear = 1899
number
0
-Infinity
uncaught exception: scala.scalajs.runtime.UndefinedBehaviorError: An undefined behavior was detected: 0 is not an instance of java.lang.Integer

[sjrd]

Fixing this requires a source-incompatible change, so it can't go in 0.6.x.

[sjrd]

So, actually, it's much worse than that: all methods of js.Date can return NaN on all engines, if the js.Date was created with an invalid string:

C:\Users\Sepi>node
> var d = new Date("foobar")
undefined
> d.getYear()
NaN
> d.getFullYear()
NaN
> d.getDay()
NaN
> d.getDate()
NaN
> d.getMonth()
NaN

etc.

So whether Firefox is allowed to return -0 in some cases is pretty irrelevant at this point. All the methods must clearly marked as returning Doubles.

Also, it's OK to call one of the setX method with NaN, in which case the date will be set to an invalid date, and therefore all methods will return NaN after that.