This bug was reported via nashorn-dev http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005142.html

Email content below for reference:

The implementation of Number.prototype.toFixed seems to be wrong in
two cases. Can you confirm this, and/or report it on an issue tracker?

Observed behaviour:

> $ jjs -version
> nashorn 1.8.0_60
> jjs> 0.5.toFixed()
> 0
> jjs> -0.5.toFixed()
> 0

Expected behaviour:

The two results should be 1 and -1 respectively.

I expect this behaviour because that is how I interpret ES5 and ES6
specifications for Number.prototype.toFixed, and because that is the
behaviour that I can observe in Chrome and Firefox.



Extra comments on possible cause of bug:

The interesting part of the ES6 specification is

20.1.3.3 - 10. - a.:

> Let n be an integer for which the exact mathematical value of n /
  10^f – x is as close to zero as possible. If there are two such n,
  pick the larger n.

In the case of `0.5.toFixed()` the expression above becomes:

> n / 10^0 - 0.5 = n / 1 - 0.5 = n - 0.5

which solves to `n = 0` or `n = 1`. It seems that Nashorn picks the
`n = 0` case instead of the `n = 1` case.



---
Esben Andreasen

-------------------

His interpretation seems right.

See spec. section:

https://es5.github.io/#x15.7.4.5

Step 8 Else, x < 1021

    Let n be an integer for which the exact mathematical value of n ÷ 10f – x is as close to zero as possible. If there are two such n, pick the larger n.