Develop Reference

getTime() not working on Safari the way it works on Chrome

What's the best way to get this to work on both Chrome and Safari? Works fine on Chrome. Returns NaN on Safari.
new Date("2018-11-22 14:24:34 -0800").getTime()

You shouldn't pass the date as a String to the constructor of Date because that causes Date.parse() to be called.
The Date.parse() method parses a string representation of a date, and returns the number of milliseconds since January 1, 1970, 00:00:00 UTC or NaN if the string is unrecognized or, in some cases, contains illegal date values (e.g. 2015-02-31).
It is not recommended to use Date.parse as until ES5, parsing of strings was entirely implementation dependent. There are still many differences in how different hosts parse date strings, therefore date strings should be manually parsed (a library can help if many different formats are to be accommodated).
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse
To mitigate those differences in implementation, I recommend you use a library like moment.js.

Try using this for the safari browser support:
new Date(("2018-11-22 14:24:34").replace(/-/g, "/")).getTime().valueOf()

Safari and Chrome showing different results of new Date() [duplicate]

I want to convert date string to Date by javascript, use this code:
var date = new Date('2013-02-27T17:00:00');
alert(date);
'2013-02-27T17:00:00' is UTC time in JSON object from server.
But the result of above code is different between Firefox and Chrome:
Firefox returns:
Wed Feb 27 2013 17:00:00 GMT+0700 (SE Asia Standard Time)
Chrome returns:
Thu Feb 28 2013 00:00:00 GMT+0700 (SE Asia Standard Time)
It's different 1 day, the correct result I would expect is the result from Chrome.
Demo code: http://jsfiddle.net/xHtqa/2/
How can I fix this problem to get the same result from both?

The correct format for UTC would be 2013-02-27T17:00:00Z (Z is for Zulu Time). Append Z if not present to get correct UTC datetime string.

Yeah, unfortunately the date-parsing algorithms are implementation-dependent. From the specification of Date.parse (which is used by new Date):
The String may be interpreted as a local time, a UTC time, or a time in some other time zone, depending on the contents of the String. 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.
To make the Date constructor not (maybe) use the local timezone, use a datetime string with timezone information, e.g. "2013-02-27T17:00:00Z". However, it is hard to find a format that is reliable parsed by every browser - the ISO format is not recognised by IE<8 (see JavaScript: Which browsers support parsing of ISO-8601 Date String with Date.parse). Better, use a unix timestamp, i.e. milliseconds since unix epoch, or use a regular expression to break the string down in its parts and then feed those into Date.UTC.

I found one thing here. It seems the native Firefox Inspector Console might have a bug:
If I run "new Date()" in the native Inspector, it shows a date with wrong timezone, GMT locale, but running the same command in the Firebug Extension Console, the date shown uses my correct timezone (GMT-3:00).

Noticed that FireFox wasn't returning the same result as Chrome. Looks like the format you use in kendo.toString for date makes a difference.
The last console result is what I needed:

Try using moment.js. It goes very well and in similar fashion with all the browsers. comes with many formatting options. use moment('date').format("") instead of New Date('date')

Date.parse() not working properly in Mozilla Firefox JavaScript

I have the string dateTime value "01-01-2013 12:00:00 AM" and parsed to DateTime using Date.parse("01-01-2013 12:00:00 AM"). This is working fine in Google Chrome and IE browser. But not working in Firefox. Anyone help how to parse this specific string to dateTime value in Mozilla Firefox.
Thanks,
Bharathi.

TL;DR You're using an invalid date format for this context, which Chrome and IE just happen to handle.
Full answer:
The specification only requires a JavaScript implementation to recognize certain formats in Date.parse. Specifically,
It accepts the RFC2822 / IETF date syntax (RFC2822 Section 3.3), e.g.
"Mon, 25 Dec 1995 13:30:00 GMT". It understands the continental US
time zone abbreviations, but for general use, use a time zone offset,
for example, "Mon, 25 Dec 1995 13:30:00 +0430" (4 hours, 30 minutes
east of the Greenwich meridian). If a time zone is not specified and
the string is in an ISO format recognized by ES5, UTC is assumed. GMT
and UTC are considered equivalent. The local time zone is used to
interpret arguments in RFC2822 Section 3.3 format (or any format not
recognized as ISO 8601 in ES5) that do not contain time zone
information.
ECMAScript 5 ISO-8601 format support
The date time string may be in ISO 8601 format. For example,
"2011-10-10" (just date) or "2011-10-10T14:48:00" (date and time) can
be passed and parsed.
Your example, 01-01-2013 12:00:00 AM, is not one of those formats. Some browsers may parse it anyway, depending on the JavaScript engine they are using, but it's non-standard. Chrome and IE happen to recognize it, but Firefox returns NaN, which is compliant with the spec:
The ECMAScript specification states: If the String does not conform to
the standard format the function may fall back to any
implementation–specific heuristics or implementation–specific parsing
algorithm. Unrecognizable strings or dates containing illegal element
values in ISO formatted strings shall cause Date.parse() to return
NaN.
See this documentation for more details.

Javascript new Date(str) - different parsing rules

I tried this in the Chrome JS console, with my locale time zone set as PST:
(new Date("07-15-2005"))
=> Fri Jul 15 2005 00:00:00 GMT-0700 (PDT)
(new Date("07-15-2005")).getTime();
=> 1121410800000
but....
(new Date("2005-07-15"))
=> Thu Jul 14 2005 17:00:00 GMT-0700 (PDT)
(new Date("2005-07-15")).getTime();
=> 1121385600000
I was expecting string parsing to occur in both. But I can't make out why when format YYYY-MM-DD is used, it assumes a timezone offset. It's as if I'm expressing "2005-07-15" in my local TZ, but "07-15-2005" is expressed in UTC.
Is the correct explanation?

The implementation seems to be vendor specific, however looking at the documentation of date parse we see that as of 1.8.5 javascript supports both RFC2822 dates and ISO 8601 dates.
As per the Date.UTC documentation ISO 8601 dates are assumed to be in UTC time if not otherwise specified and thus the timezone difference is automatically added.
RFC2822 dates seem to be assumed as local times and as such are not modified.

I cannot seem to replicate your results, but the results seem to differ from browser to browser.
See: http://jsfiddle.net/f7DMV/
In Firefox and Opera, I get only the middle line parsing correctly, the others are Invalid Dates.
In Chrome, both the first and the second line parse correctly (and don't differ), but the last one is still Invalid.

It will vary from browser to browser. The ECMA262 spec says any string which is not in YYYY-MM-DD format and is passed to the Date function, it may fall back to implementation-specific heuristics or implementation-specific date formats.

Javascript Date.parse bug when dash-delimited and starts with year

Am seeking confirmation if this is a bona fide documentation and/or implementation bug with Javascript's Date.parse method.
The docs I'm referring to are at https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Date/parse and they say 'If you do not specify a time zone, the local time zone is assumed.'
But the following code shows that, despite not specifying a time zone, local time is not being assumed (but rather my timezone offset is being applied), if the string passed to Date.parse begins with the 4-digit year representation, and is dash-delimited.
var euroStyleDate = '2011-10-04';
var amerStyleDate = '10/04/2011';
var euroStyleParsed = Date.parse(euroStyleDate);
var amerStyleParsed = Date.parse(amerStyleDate);
console.log(euroStyleParsed); //1317686400000
console.log(amerStyleParsed); //1317700800000
console.log(new Date(euroStyleParsed));
//Date {Mon Oct 03 2011 20:00:00 GMT-0400 (Eastern Daylight Time)}
console.log(new Date(amerStyleParsed));
//Date {Tue Oct 04 2011 00:00:00 GMT-0400 (Eastern Daylight Time)}
There may even be other cases, and I'm sure I'm not the first to discover this if I am incorrect. So beyond confirmation, I'd surely love to be pointed at more in-depth information on this if anybody knows of pertinent links.
I'm experiencing this in FF3, Chrome for Windows and of course just to be special IE8 doesn't even seem to able to perform the conversion on 2011-10-04 whatsoever: I'm just getting an empty string in my application
Thanks in advance for any further insight or resources.

I ran into this concept, too. For anyone googling "Javascript dates dashes slashes" like I was, this is the clearest demonstration that I can think of as to what's going on here.
In short, slashes means local time zone, and dashes means UTC. Other answers has explanations regarding why.
<script type="text/javascript">
var
testB = new Date("2012/02/09"),
testC = new Date("2012-02-09");
alert(testB.toString());
alert(testC.toString());
alert(testC.toUTCString());
</script>

**Update:**It looks like there are several different standards at work here:
The EMCAScript < 5 standard allowed for dates in the standard IETF format, e.g. Sun Oct 03 2010. With these dates, the local timezone is assumed.
In ECMAScript 5, a limited version of the ISO 8601 standard is also allowed, e.g. 2010-10-03. The spec seems to say (perhaps following ISO 8601?) that in this case, the UTC timezone is assumed if one is not specified.
I haven't found a spec that says Date.parse can handle mm/dd/yyyy dates, but my browser (Chrome 14) clearly can, and probably other browsers can too. This appears to follow standard 1 above, assuming the local timezone. Given that it's not in the spec, however, I would recommend not using this version, as it's likely to be browser-dependent (and I have no idea whether 10-03-2010 would result in a different date if I had a European locale set on my browser).
There are a few issues with the native Date.parse function in most interpreters - I have often had timezone issues like the one you describe. So in general, I either use a library like Datejs or I write my own parsing functions. The DateTime module of the SIMILE AJAX library has a pretty good example function for parsing ISO-8601 dates (what you're referring to as euroStyleDate, plus an optional time component).
When setting dates, I generally use new Date() and then use the setUTC*() functions to set the different date elements to my desired precision. It's not perfect, but at least you're dealing with a clear timezone.