new Date() works differently in Chrome and Firefox

Question

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?

for me in chrome it shows `Wed Feb 27 2013 22:30:00 GMT+0530 (India Standard Time)` and in firefox `Wed Feb 27 2013 17:00:00 GMT+0530 (India Standard Time)` — Sandeep, Feb 27 '13 at 10:42
@Sandeep the main point is that Chrome adds timezone offset while Firefox doesn't — default locale, Feb 27 '13 at 10:43
@CuongLe Have you seen this question: http://stackoverflow.com/questions/9062863/firefox-new-date-from-string-constructs-time-in-local-time-zone?rq=1 — default locale, Feb 27 '13 at 10:44
It's `Date {Wed Feb 27 2013 17:00:00 GMT+0000 (GMT)}` for me in both (Linux). — marekful, Feb 27 '13 at 10:45
possible duplicate of [(new Date('2012-12-01')).getMonth() === 10?](http://stackoverflow.com/questions/14311779/new-date2012-12-01-getmonth-10) — Bergi, Feb 27 '13 at 10:55

score 69 · Accepted Answer · answered Feb 27 '13 at 10:56

69

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.

answered Feb 27 '13 at 10:56

Petr Abdulin

33,883
9
62
96

2

Thanks. This works. But there is an log saying, it will be deprecated in future !!!. Any Idea please? – Débora Mar 23 '16 at 17:21
1

thanks a lot, i've been sitting with this issue for two days, but this post solved everything. – Piyal George Sep 25 '17 at 13:11

score 31 · Answer 2 · edited May 11 '18 at 15:41

31

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.

edited May 11 '18 at 15:41

harriyott

10,505
10
64
103

answered Feb 27 '13 at 11:01

Bergi

630,263
148
957
1,375

2

But the spec (15.9.1.15) actually says: "The value of an absent time zone offset is “Z”" - so it should NOT be implementation dependent – sinelaw Dec 12 '13 at 23:25
12

OK, correction. Looks like a [mistake in the ES5.1 spec](https://bugs.ecmascript.org/show_bug.cgi?id=112) - the intention was to match ISO-8601 where missing Z means local time (so Chrome matches ES5.1, Firefox & IE match ISO-8601) – sinelaw Dec 12 '13 at 23:34
@sinelaw: Thanks for further investigating that point. However, regardless what the spec states, [old] browsers still are doing it differently :-) – Bergi Dec 12 '13 at 23:51
@sinelaw: Can you add that to the answer? It's important – Lightness Races in Orbit Jul 02 '14 at 15:17
2

Oddly using Date.Parse vs. new Date fixed the issue I was having where Chrome would convert the date to the local time zone instead of treating it as already in the local time zone. – KingOfHypocrites Jul 21 '14 at 17:20
1

@KingOfHypocrites—that's a bit weird as calling the Date constructor [*with a string*](http://ecma-international.org/ecma-262/5.1/#sec-15.9.3.2) is supposed to be the same as using *Date.parse*. – RobG Jan 25 '15 at 06:18

score 4 · Answer 3 · answered Nov 24 '15 at 12:56

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).

score -3 · Answer 4 · edited Aug 05 '16 at 01:13

-3

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:

edited Aug 05 '16 at 01:13

Pang

9,564
146
81
122

answered Aug 04 '16 at 22:52

MJ Storm

1

MSIslam · Answer 5 · 2016-01-23T04:12:34.040

-4

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')

edited Jan 23 '16 at 04:12

answered Jan 22 '16 at 18:08

MSIslam

4,587
6
25
28

new Date() works differently in Chrome and Firefox

5 Answers5

Linked

Related