0

Chrome not giving a correct result on date conversion:

Date : "2017-05-22T14:00:00"

On doing this in chrome console:

new Date("2017-05-22T14:00:00");

Output is:

Mon May 22 2017 14:00:00 GMT+0530 (IST)

This is wrong because I am in IST. It should have rather given output as 

Mon May 22 2017 19:30:00 GMT+0530 (IST)

Safari is giving correct results. Chrome was right before but I think latest update is having an issue.

Found that appending Z in date string results correct date value.

new Date("2017-05-22T14:00:00Z");
Shashwat Tripathi
  • 572
  • 1
  • 5
  • 19
  • Is there any technical reason to use the string-format constructor? [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date) summarises it wonderfully: *parsing of date strings with the Date constructor (and Date.parse, they are equivalent) is strongly discouraged due to browser differences and inconsistencies* – Álvaro González May 22 '17 at 14:24
  • Receiving date as string, "2017-05-22T14:00:00" in this format from the service and I can't modify the service. What should be the way then to get correct results? – Shashwat Tripathi May 22 '17 at 14:31
  • Reported to chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=725080&can=2&start=0&num=100&q=&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort= – Shashwat Tripathi May 22 '17 at 14:33
  • See [*Why does Date.parse give incorrect results?*](https://stackoverflow.com/questions/2587345/why-does-date-parse-give-incorrect-results) This isn't a bug, it's how ISO 8601 strings without a timezone are supposed to be parsed (but you shouldn't be using the built-in parser anyway). – RobG May 22 '17 at 20:51

1 Answers1

2

The input value is being interpreted correctly. ECMAScript 2015 (ES6) section 20.3.1.16 states:

If the time zone offset is absent, the date-time is interpreted as a local time.

This aligns with the ISO-8601 standard as well.

In previous versions of ECMAScript, UTC was assumed when no offset was provided. That goes against ISO-8601, and was implemented inconsistently across various environments.

If you want the input to be interpreted as UTC, then you should provide an offset, either +00:00, or Z as part of the input string.

However, if you are talking about how a Date object should be displayed when logged to the debug console, that is not defined in the spec. In some environments, you will see the output of date.toString(), which shows the local date and time in a non-standard format, and in other environments (such as FireFox) you will see the output of date.toISOString(), which shows the UTC date and time in ISO-8601 format.

There's no spec about which to show, so either would be valid. If you want to see specific output, don't just log a Date object, call a function on the object that returns a string and log that instead.

Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575
  • So does that mean it was not correct before because for the same dateTime string i.e. without "Z" at the end chrome was considering it as UTC and converting it to localTimeZone? I am seeing this after the chrome update. – Shashwat Tripathi May 22 '17 at 18:30
  • And also does that mean that safari is doing it wrong because safari is considering dateTime without "Z" as UTC and converting it to local timezone as chrome was doing it before. – Shashwat Tripathi May 22 '17 at 18:31
  • By ISO8601, a value without an offset is local time. ES5.1 and lower had this wrong, and they corrected it in ES6. Previously, some browsers took it as local time and some took it as UTC. Nowadays, all browsers should treat it as local time. Is it the latest version of Safari? If so, they have a bug. – Matt Johnson-Pint May 22 '17 at 19:15
  • 1
    Also note that date-only forms without an offset are still interpreted as UTC, even though it goes against ISO8601. This was deliberate, as ALL prior implementations treated date-only in YYYY-MM-DD format as if it were UTC (even though ISO8601 says the exact opposite). Also, I covered this (in part) in [my recent talk at JSConfEU](https://youtu.be/aVuor-VAWTI). – Matt Johnson-Pint May 22 '17 at 19:18
  • Can you please tell me how to convert this "2017-05-23T04:00:00.000Z" into UTC format Date object. – Shashwat Tripathi May 22 '17 at 21:38
  • Your question doesn't make sense. Date objects don't contain a format, they are just a number of milliseconds since the Unix epoch. Also UTC is not a format. What do you actually want to accomplish? – Matt Johnson-Pint May 22 '17 at 21:45
  • I have two property a) .forecast_local and b) .forecast_utc. Now I want to have javascript Date object in both the property in respective form. Like forecast_local as +-GMT and forecast_utc as date object which is having value same as received from service like "2017-05-23T04:00:00.000Z". Because service is sending zulu time. – Shashwat Tripathi May 22 '17 at 21:50
  • 1
    You can't. JS Date objects don't work that way. They do not hold any time zone information whatsoever, regardless of how they were initialized. They internally represent ms since unix epoch, and some functions use the system local time zone when they are invoked. You could use a string, or a `moment` object (with moment.js), but not a `Date`. Also, you're chaining questions here in comments - this last part should be its own separate question. – Matt Johnson-Pint May 22 '17 at 22:13
  • @ShashwatTripathi—browsers are all over the place on this, though they are getting to be consistent with the spec you can't rely on it. Far better to use a parser and formatter library (e.g. [*moment.js*](https://momentjs.com/) or [*fecha.js*](https://github.com/taylorhakes/fecha)) or write your own functions if you only have one or two formats to deal with. – RobG May 23 '17 at 01:45