Bug 40820 - Values passed to Date() not validated - Invalid values not trapped
Summary: Values passed to Date() not validated - Invalid values not trapped
Status: UNCONFIRMED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Critical
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-18 02:01 PDT by ext-sowmini.philip
Modified: 2011-08-06 21:10 PDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ext-sowmini.philip 2010-06-18 02:01:06 PDT
PROBLEM STATEMENT : Date constructors automatically convert all date/time values to the corresponding time since Jan1970 without validation of values passed.
Eg,  Date("July 28, 2010 23:170")
     Date("July 32, 2010 23:17")
     Date(2010,1,30,23,170,00,00)
are all converted to valid dates.

The values passed should be validated and the fact that there doesn't exist a Feb30 or July32,etc must be detected and reported.
Comment 1 Adam Peller 2010-06-18 07:33:40 PDT
Another test case:
isNaN(new Date("")) should be true
Comment 2 Gavin Barraclough 2011-08-06 21:10:15 PDT
(In reply to comment #0)
> PROBLEM STATEMENT : Date constructors automatically convert all date/time values to the corresponding time since Jan1970 without validation of values passed.
> Eg,  Date("July 28, 2010 23:170")
>      Date("July 32, 2010 23:17")
>      Date(2010,1,30,23,170,00,00)
> are all converted to valid dates.
> 
> The values passed should be validated and the fact that there doesn't exist a Feb30 or July32,etc must be detected and reported.

Per ES5 it is not necessary to considered this a bug:

    "The function first attempts to parse the format of the String according to the rules called out in Date Time String Format (15.9.1.15). If the String does not conform to that format the function may fall back to any implementation-specific heuristics or implementation-specific date formats."

Implementation-specific extended support is explicitly permitted, and other browsers appear to support these dates, so changing our behavior may raise compatibility concerns.  There might be a benefit to developers in validating input here, but this is weakened a little by the fact that it doesn't look like malformed dates are an early in the spec.
Comment 3 Gavin Barraclough 2011-08-06 21:10:53 PDT
(In reply to comment #1)
> Another test case:
> isNaN(new Date("")) should be true

This works for me now, I think there have been some fixes in this area recently.