views:

46

answers:

2

Does anyone know why in Firefox if you execute the code below it will validate it as a date if the string passed in is four numbers and only four numbers? In every other browser I tested with (IE, Chrome) it will always return as not a date.

Being that the spec, as pointed out by Marcel Korpel below, states that it should fall back to use the Firefox's implementation-specific fall back I am really wondering why Firefox's fall back displays this anomaly.

function isDate(sDate) {  
    var temp = new Date(sDate);  
    if (temp.toString() == "NaN" || temp.toString() == "Invalid Date") {  
        alert("Not a Date");  
    } else {  
        alert("Is a Date!");  
    }
}
+1  A: 

If you pass a string to the Date constructor, the string should be in a format recognized by the parse method (IETF-compliant RFC 1123 timestamps) (source: MDC). Everything else results in implementation specific behaviour and will vary across browsers.

I suggest you don't use strings at all and either use three numbers representing year, month and day (mind that month numbers begin at 0 (= January)), or use one number, the number of milliseconds since 1 January 1970 00:00:00 UTC.

UPDATE: seeing your example,

var a = new Date('0123');
console.log(a);

outputs

Fri Jan 01 0123 01:00:00 GMT+0100 (CET)

so Firefox apparently recognizes '0123' as a year number.

UPDATE 2: I think MDC's description of Date.parse contains the answer to your question:

Starting in JavaScript 1.8.5, a subset of ISO 8601 formatted date strings can also be parsed.

The ISO 8601 page specifies (section 'Formats'):

Year:
YYYY (eg 1997)
Year and month:
YYYY-MM (eg 1997-07)
Complete date:
YYYY-MM-DD (eg 1997-07-16)

So when relying on ISO 8601, a string only containing four numbers will be recognized as a year number.

Marcel Korpel
I understand it is not compliant, I was just wondering why Firefox would display this behavior.
Brian S.
@Brian: it's just because of that, it's behaviour is not specified; according to the [ECMAScript spec](http://ecma262-5.com/ELS5_Section_15.htm#Section_15.9.4.2), “[i]f the String does not conform to that format the function may fall back to any implementation-specific heuristics or implementation-specific date formats.” The `Date` constructor *should* return `NaN` if the string isn't recognized as a date. It's just that some browsers are more forgiving than others.
Marcel Korpel
@Marcel I guess I am really asking why Firefox's implementation-specific fall back will return NaN for '123' but a date for '0123'. Should I edit my post to better qualify my question?
Brian S.
That is even odder still. So for some reason Firefox will accept '0000' as a valid year? Might this be a bug?
Brian S.
Ahh now I get it. When passing in a string, Firefox attempts to do a date.parse on it and '1234' happens to work where as '123' does not.Thank you!
Brian S.
A: 

I have encountered the same issue as with this in firefox, for some reasons I cannot explain any 4 digit numeric chars is a valid date in FF, in other browsers this is NaN:

A bit nasty work-around for FF but, this worked for me:

function isDate(sDate) {  
    if(sDate.match(/^\d{4}$/))
       return false;
    var temp = new Date(sDate);  
    if (temp.toString() == "NaN" || temp.toString() == "Invalid Date") {  
        alert("Not a Date");  
    } else {  
        alert("Is a Date!");  
        return true;  
    }
}
jerjer
Thanks for the workaround! I think I will use something like this in my code as well.
Brian S.