Perform more aggressive time to NaN conversions. Our internal date...

Perform more aggressive time to NaN conversions. Our internal date
methods rely on the time values passed in being within a certain range
- not significantly larger than the the ECMA 262 specified time
range. When creating a time, always make it NaN if there is no way
that it can be within range even after UTC conversion.


Committed: http://code.google.com/p/v8/source/detail?r=6048

[Mads Ager (chromium), 2010-12-16 11:05:11]

Redirecting since Erik is out.

[Søren Thygesen Gjesse, 2010-12-16 11:38:30]

LGTM

http://codereview.chromium.org/5905003/diff/5001/src/date.js
File src/date.js (right):

http://codereview.chromium.org/5905003/diff/5001/src/date.js#newcode371
src/date.js:371: var time = day * msPerDay + time;
As you mentioned offline please add tests where day and time have different
Infinity/-Infinity values to ensure NaN is returned.

[William Hesse, 2010-12-16 18:56:51]

If the only time a NaN value is assigned to a Date object is explicitly in our
code, maybe the test for NaN in all the Date methods could be replaced with a
faster check for exact equality with that particular NaN.  This would need to be
an inlined method.


On 2010/12/16 11:38:30, Søren Gjesse wrote:
> LGTM
> 
> http://codereview.chromium.org/5905003/diff/5001/src/date.js
> File src/date.js (right):
> 
> http://codereview.chromium.org/5905003/diff/5001/src/date.js#newcode371
> src/date.js:371: var time = day * msPerDay + time;
> As you mentioned offline please add tests where day and time have different
> Infinity/-Infinity values to ensure NaN is returned.