Adventures in JavaScript number parsing

The problem with replacing parseInt with the unary + operator is that they don't have the same semantics. +"" evaluates to 0, while parseInt("", 10) evaluates to NaN. Tricks like this are fine if you know that it won't matter for your input, but generally speaking you're better off with parseInt and a radix. Yes, it's unnecessarily verbose for the normal case, but it's not <i>that</i> verbose.<p>A couple of other odd cases: +[] evaluates to 0, while +{} evaluates to NaN (parseInt([], 10) evaluates to NaN). +new Date evaluates to the integer representation of the current Unix timestamp; parseInt(new Date, 10) evaluates to NaN.

I don't like abusing String prototype but:<p><pre><code> String.prototype.toInt=function(){ return parseInt(this,10) } </code></pre> then:<p><pre><code> "08".toInt() // ==&#62; 8</code></pre>

I wonder what made the original coder on javascript assume that base10 should not ALWAYS be the default unless told otherwise.<p>At least all the different browsers' versions of javascript are consistent about that (right?)

This is not unique to Javascript. To a Java programmer this behavior seems natural(octal literals lead with a 0) and not really worthy of a angry blog post.

Well, it also parses hex numbers prefixed with 0x... Hard to be surprised after the first time you get tripped by it.