Develop Reference

is there any workaround for broken v8 date parser?

V8 Date parser is broken:
> new Date('asd qw 101')
Sat Jan 01 101 00:00:00 GMT+0100 (CET)
I can use fragile regular expression like this:
\d{1,2} (jan|feb|mar|may|jun|jul|aug|sep|oct|nov|dec) \d{1,4}
but it is too fragile. I cannot rely on new Date (issue in V8) and also moment cant help me because moment is getting rid off date detection (github issue-thread).
is there any workaround for broken v8 date parser?
To be clear. We have Gecko and V8, both have Date. V8 has broken Date, Gecko has working one. I need the Date from in Gecko (Firefox).
Update: It’s definitely broken parser https://code.google.com/p/v8/issues/detail?id=2602
nope, Status: WorkingAsIntended

Date objects are based on a time value that is the number of milliseconds since 1 January, 1970 UTC and have the following constructors
new Date();
new Date(value);
new Date(dateString);
new Date(year, month[, day[, hour[, minutes[, seconds[, milliseconds]]]]]);
From the docs,
dateString in new Date(dateString) is a string value representing a date. The string should be in a
format recognized by the Date.parse() method (IETF-compliant RFC 2822
timestamps and also a version of ISO8601).
Now looking at the v8 sourcecode in date.js:
function DateConstructor(year, month, date, hours, minutes, seconds, ms) {
if (!%_IsConstructCall()) {
// ECMA 262 - 15.9.2
return (new $Date()).toString();
}
// ECMA 262 - 15.9.3
var argc = %_ArgumentsLength();
var value;
if (argc == 0) {
value = %DateCurrentTime();
SET_UTC_DATE_VALUE(this, value);
} else if (argc == 1) {
if (IS_NUMBER(year)) {
value = year;
} else if (IS_STRING(year)) {
// Probe the Date cache. If we already have a time value for the
// given time, we re-use that instead of parsing the string again.
var cache = Date_cache;
if (cache.string === year) {
value = cache.time;
} else {
value = DateParse(year); <- DOES NOT RETURN NaN
if (!NUMBER_IS_NAN(value)) {
cache.time = value;
cache.string = year;
}
}
}
...
it looks like DateParse() does not return a NaN for for a string like 'asd qw 101' and hence the error. You can cross-check the same with Date.parse('asd qw 101') in both Chrome(v8) [which returns -58979943000000] and Gecko (Firefox) [which returns a NaN]. Sat Jan 01 101 00:00:00 comes when you seed new Date() with a timestamp of -58979943000000(in both browsers)
is there any workaround for broken v8 date parser?
I wouldnt say V8 date parser is broken. It just tries to satisfy a string against RFC 2822 standard in the best possible way but so does gecko and both break gives different results in certain cases.
Try new Date('Sun Ma 10 2015') in both Chrome(V8) and Firefox(Gecko) for another such anomaly.
Here chrome cannot decide weather 'Ma' stands for 'March' or 'May' and gives an Invalid Date while Firefox doesnt.
Workaround:
You can create your own wrapper around Date() to filter those strings that V8's own parser cannot. However, subclassing built-ins in ECMA-5 is not feasible. In ECMA-6, it will be possible to subclass built-in constructors (Array, Date, and Error) - reference
However you can use a more robust regular expression to validate strings against RFC 2822/ISO 8601
^(?:(?:31(\/|-|\. |\s)(?:0?[13578]|1[02]|(?:Jan|Mar|May|Jul|Aug|Oct|Dec)))\1|(?:(?:29|30)(\/|-|\.|\s)(?:0?[1,3-9]|1[0-2]|(?:Jan|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec))\2))(?:(?:1[6-9]|[2-9]\d)?\d{2})$|^(?:29(\/|-|\.|\s)(?:0?2|(?:Feb))\3(?:(?:(?:1[6-9]|[2-9]\d)?(?:0[48]|[2468][048]|[13579][26])|(?:(?:16|[2468][048]|[3579][26])00))))$|^(?:0?[1-9]|1\d|2[0-8])(\/|-|\.|\s)(?:(?:0?[1-9]|(?:Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep))|(?:1[0-2]|(?:Oct|Nov|Dec)))\4(?:(?:1[6-9]|[2-9]\d)?\d{2})$
Image generated from debuggex
So, seems like v8 aint broken, it just works differently.
Hope it helps!

You seem to be asking for a way to parse a string that might be in any particular format and determine what data is represented. There are many reasons why this is a bad idea in general.
You say moment.js is "getting rid of date detection", but actually it never had this feature in the first place. People just made the assumption that it could do that, and in some cases it worked, and in many cases it didn't.
Here's an example that illustrates the problem.
var s = "01.02.03";
Is that a date? Maybe. Maybe not. It could be a section heading in a document. Even if we said it was a date, what date is it? It could be interpreted as any of the following:
January 2nd, 2003
January 2nd, 0003
February 1st, 2003
February 1st, 0003
February 3rd, 2001
February 3rd, 0001
The only way to disambiguate would be with knowledge of the current culture date settings. Javascript's Date object does just that - which means you will get a different value depending on the settings of the machine where the code is running. However, moment.js is about stability across all environments. Cultural settings are explicit, via moment's own locale functionality. Relying on the browser's culture settings leads to errors in interpretation.
The best thing to do is to be explicit about the format you are working with. Don't allow random garbage input. Expect your input in a particular format, and use a regex to validate that format ahead of time, rather then just trying to construct a Date and seeing if it's valid after the fact.
If you can't do that, you'll have to find additional context to help decide. For example, if you are scraping some random bits of the web from a back-end process and you want to extract a date from the text, you'd have to have some knowledge about the language and locale of each particular web page. You could guess, but you'd likely be wrong a fair amount of the time.
See also: Garbage in, garbage out

ES5 15.9.4.2 Date.parse: /.../ If the String does not conform to
that format the function may fall back to any implementation-specific
heuristics or implementation-specific date formats. Unrecognizable
Strings or dates containing illegal element values in the format
String shall cause Date.parse to return NaN.
So that's all right and according to the citation above result of v8 date parser:
new Date('asd qw 101') : Sat Jan 01 101 00:00:00 GMT+0100
(CET)
new Date('asd qw') : Invalid Date

Javascript: Difference between `new Date(dateString)` vs `new Date(year, month, day)`

Referencing to the accepted answer on this question How do I get the number of days between two dates in JavaScript?. I see, in the function parseDate:
function parseDate(str) {
var mdy = str.split('/')
return new Date(mdy[2], mdy[0]-1, mdy[1]);
}
He is doing this:
var mdy = str.split('/')
return new Date(mdy[2], mdy[0]-1, mdy[1]);
i.e. splitting the passed date into month, day and year and then passing it on to Date like new Date(year, month, day) while he could simply do new Date(str) and it would have returned the same result (Wouldn't it?). Can anyone please explain the difference between both the ways?
Update: Test results:
var str = '1/1/2000'
var mdy = str.split('/')
console.log( new Date(str) ) // Sat Jan 01 2000 00:00:00 GMT+0500 (Pakistan Standard Time)
console.log( new Date(mdy[2], mdy[0]-1, mdy[1]) ); // Sat Jan 01 2000 00:00:00 GMT+0500 (Pakistan Standard Time)

No, they're not the same (even assuming you'll subtract one month later: he's doing mdy[0] - 1) because new Date(str) is required (by standard, see §15.9.4.2) to accept only date in a specific format ISO 8601 (YYYY-MM-DDTHH:mm:ss.sssZ, see also this post, I won't repeat myself here):
If the String does not conform to that format [ISO 8601] the function may fall back to any implementation-specific heuristics or implementation-specific date formats.
Please note (as pointed out by Royi in comments) that also RFC 2822 should be supported (according to MDN) but it's not mentioned in JavaScript specifications and Internet Explorer doesn't officially support it (see MSDN, it can parse something similar but it's not the same).
In that code they're parsing using a specific locale rules (MM/DD/YYYY, I suppose en-US locale but it's not only one). To be honest I wouldn't even use that code for parsing (because yes, actually it'll be broken for a different locale: even separator used for splitting is not "locale safe"). Let me explain with an example:
You're using a proper configured date time picker (or <input type="date"/> when supported) you'll enter date according to your locale. For example in Italy (but in general in Europe) we write DD/MM/YYYY.
Now let's imagine that user picked 21 December 2014 (formatted as 21/12/2014 according to his locale).
With string splitting that code will fail (because it'll pick 21 as month number, obviously it's not valid). Even worse than that such errors may even go unnoticed (for example if user picks 1/2/2014 code will "think" it's 2nd Jan but user picked 1st Feb). Do you want to make it more complicate? Even new Date(str) may fail because it's browser dependent (and you can't really trust heuristic to be portable and safe).
If you're asking yourself "Then why they used such code?" I'd say that they used a quick workaround to support dates using en-US locale (probably because browser they used didn't support them with heuristic guess) but it's not something you should reuse.
Solution? Do not ever parse date by hand (unless you really and deep know what you're doing), use a good library (for example moment.js) for that because most assumption you may do about date formatting are...wrong.

I tried to enter your test code into jsperf.com, and the results on my machine are clear, and they say that you should not try to split the string.
I tried two tests for the test using a split string, and supprisingly, the split itself was not what was taking up the time.
Try for yourself at http://jsperf.com/date-from-string-or-dateparts

What is up with javascript Date function for only years?

(EDIT: I am using chrome console for the code below)
I realize that javascript Date() is deprecated, but it's useful for something I'm currently working on; however there is a strange problem:
var x = new Date('999').getFullYear()
returns 999
while
var x = new Date('1000').getFullYear()
returns 999 as well, but
var x = new Date('10000').getFullYear()
returns 10000...
Does anyone know why do 4 digit numbers give the wrong .getFullYear()?

As the other answers suggest, you can't rely on Date.parse across browsers, especially if you are dealing with dates before 1000 CE.
As far as Chrome is concerned, it looks like the issue is how the browser deals with timezones. The following example suggests that before 1000 CE, Chrome parses the date in your local timezone on top of it; >= 1000 CE, it appears to first parse the date in UTC, then applies the timezone conversion:
> new Date('1000')
"Tue Dec 31 999 16:00:00 GMT-0800 (PST)"
> new Date('999')
"Tue Jan 01 999 00:00:00 GMT-0800 (PST)"
I'd be inclined to see this as a bug, but perhaps the Chromium team thinks it's a feature :).
The bottom line is that, if you want accurate date parsing for years, especially ancient years, you need to do some work yourself and/or use a library. Moment.js and Datejs both might help, but I doubt either deals well with ancient years. Moment.js seems to have the same issue (in Chrome):
> moment('999').year()
999
> moment('1000').year()
999
The best way I know of to accurately set dates based on ancient years is generally to a) always use UTC, and b) set the date manually:
var d = new Date();
d.setUTCFullYear('999');
d.getUTCFullYear(); // 999
d.setUTCFullYear('1000');
d.getUTCFullYear(); // 1000
In Chrome at least, this works with both strings and integers.
You might also be interested in the gregorian parser in the Timemap.js library, which handles ancient years with AD, CE, BC, and BCE extensions, as well as negative numbers.

Take a look at this page. You are passing a string which is passed to this parse method. The first argument isn't "years" unless you pass 3 integers. Finally while the class itself isn't being deprecated, some of it's members are (including getYear() which is being replaced with getFullYear() which you are using`)

This fiddle says otherwise on Firefox. Perhaps it's browser related?

alert(new Date('999').getFullYear()); yields NaN on Firefox 15.0.1
Hmm.. Chrome 21.0.1180.57 does yield '999'

var x = new Date('10000').getFullYear()
change it to
var x = new Date(10000).getFullYear()
you are sending an invalid datestring to the date constructor.

Invalid date/None showing up for JS Date object in IE/Firefox

I am displaying a date time object in a table however for some reason in IE it display as None or Invalid Date is there something wrong with my format or is there an easy way for making this more readable such as mm/dd/yyyy HH:MM
this is what displays in chrome:
Mon Nov 28 2011 16:00:00 GMT-0500 (EST)
This is being converted from a Unix timestamp to that output in an API layer.

Probably the creation of the Date object fails, because the new Date() constructor accepts just some limited, implementation-dependent set of date strings.
You can use the Globalize library to deal with such issues, even if no localization in the usual sense is involved—but dealing with different string presentations of dates as is localization of a kind. It first looks a bit messy (it takes some time to dig into it—my book “Going Global with JavaScript and Globalize.js” contains a more readable description of it, with many examples), and it’s far from perfect, but it’s very useful.
If you know that your timestamp data is of some known exact format, you can parse it easily and then output it according to your own format descriptor. Assuming, for the sake of definiteness, that the format is the one exemplified with
Mon Nov 28 2011 16:00:00 GMT-0500 (EST)
(I know it’s an output format you mentioned, but I just use it as an example), you would first do simple string operation to discard the “GMT” and “(EST)” part (Globalize cannot currently handle them), producing e.g.
Mon Nov 28 2011 16:00:00 -05:00
and then you would just use code like the following:
var foo = Globalize.parseDate(timestamp,'ddd MMM d yyyy HH:mm:ss zzz');
var out = Globalize.format(foo,'MM/dd/yyyy HH:MM');
document.write(out);

just make your own method to format the date as string so you pass all problems with diffrent browsers and plateforms

I suspect Chrome is being helpful here and calling the .toString() method for you.
The Date object has several methods for formatting string output. See the w3schools reference page for examples.

js Date toLocaleString

I use the 3 browsers to output this result.
Chrome:
new Date().toLocaleString()
> "Sun Sep 04 2011 21:40:04 GMT+0800 (HKT)"
Safari:
new Date().toLocaleString()
> "2011年9月4日 下午09时54分51秒格林尼治标准时间+0800"
FF:
new Date().toLocaleString()
> "Sun Sep 4 21:46:03 2011"
why not the same output result? timezoom?

It depends on the configuration of the computer, the user's preferred date format, obviously the user's locale, and how the browser determines this.
You should really prefer using a proper date library such as datejs for formatting.
See their Date.toString() and format specifiers.

That's a bug in webkit, actually; in particular in Chrome but Safari is indeed affected too: http://code.google.com/p/chromium/issues/detail?id=3607
toLocaleString() does not translate to the locale!
The worst is, it's closed as WontFix. How is that possible? We should try and re-open it. The conclusion on the bug is that somewhen a new javascript globalization apis (that is well explained here) will appear. That doesn't sound like a solution to me!
In any case, if possible, follow #arnaud576875 suggestion to use datejs which is old but still very good.

Check this link
And this example:
var event = new Date(Date.UTC(2012, 11, 20, 3, 0, 0));
// British English uses day-month-year order and 24-hour time without AM/PM
console.log(event.toLocaleString('en-GB', { timeZone: 'UTC' }));
// expected output: 20/12/2012, 03:00:00
// Korean uses year-month-day order and 12-hour time with AM/PM
console.log(event.toLocaleString('ko-KR', { timeZone: 'UTC' }));
// expected output: 2012. 12. 20. 오전 3:00:00