3

Knowing that my timezone is GMT+2, consider the following code:

  • Running On a Selfy 4G phone: 

    myDate = "2017-05-12T09:00:00";
dateFoo = new Date(myDate); //  Fri May 12 2017 11:00:00 GMT+0200 (CEST)

  • Running on a Galaxy S7:

    myDate = "2017-05-12T09:00:00";
dateFoo = new Date(myDate); //  Fri May 12 2017 09:00:00 GMT+0200 (CEST)

Why is there an inconsistency in the outputs and how would I go about solving it?

My question is different from other similar questions (such as Why does Date.parse give incorrect results?) because in my case I am using the exact same string and it's the devices that differ.

Community
  • 1
  • 1
edoreld
  • 303
  • 1
  • 17
  • 1
    Another possible dupe: http://stackoverflow.com/q/6427204/5743988 – 4castle May 11 '17 at 13:48
  • I don't think this is a duplicate of that bug @4castle — the dates in this question look like well-formed ISO dates, albeit without explicit time zone. – Pointy May 11 '17 at 13:48
  • 1
    @Pointy The input may be well-formed, but the implementation of the `Date` parser isn't standardized, so that's reason enough for any inconsistency. – 4castle May 11 '17 at 13:49
  • Well since the difference here is 2 hours, I think it's the lack of time zone info in the date strings that must be the issue. OP if your date strings end with "+02" does it work? – Pointy May 11 '17 at 13:51
  • Which browsers are you using on these devices? – Gregor Menih May 11 '17 at 13:54
  • 1
    What I'm saying is, never use `Date.parse` or `new Date` to parse a date string that didn't come from a `Date.toString()`, because the standard is iffy, and it doesn't matter what browser or what device you're using, it shouldn't be expected to be consistent in the first place. – 4castle May 11 '17 at 13:56
  • Well, it *is* standardized (in ES2015 at least), but not all browsers follow the standard, and in this case because those date strings lack the explicit time zone they're out of compliance. – Pointy May 11 '17 at 14:02
  • 1
    @Pointy—ECMA-262 does not require a timezone, so "2017-05-12T09:00:00" is consistent with the standard and should be treated as "local". Though it is a terrible idea to rely on the built-in Date parser. – RobG May 11 '17 at 22:44
  • @RobG I read the spec as insisting on the "Z" suffix in its syntax description, but maybe it's optional. – Pointy May 12 '17 at 01:19

2 Answers2

0

The initial problem was that Date.parse on one device took my local time as the time zone, whereas on the other device it took UTC.

By appending a Z at the end of my initial dateString, I forced the date to always be considered as UTC no matter what the device, therefore achieving consistent results with Date.parse().

In order to then get the date in my local time, I used the answer to this question: https://stackoverflow.com/a/1486612/1875581.

Community
  • 1
  • 1
edoreld
  • 303
  • 1
  • 17
  • I don't recommend you use this as a permanent solution. It's been said [many](http://stackoverflow.com/a/6427318/5743988) [times](http://stackoverflow.com/a/2587398/5743988) [before](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse) that date parsing with `new Date` or `Date.parse` is bad practice because of inconsistent browser implementations until ES6. You're advised to use a 3rd party date parsing library if you want consistent results. (Such as [moment.js](https://momentjs.com/)). – 4castle May 11 '17 at 14:10
  • Thanks, in my case there is a large variety of devices, so I will definitely take a look at moment.js. – edoreld May 11 '17 at 14:16
  • Appending Z is bad idea. "2017-05-12T09:00:00" **should** be parsed as local, but appending a Z will parse it as UTC. The bottom line is never use the built-in parser, use a function or library. The linked answer ([*JSON Stringify changes time of date because of UTC*](http://stackoverflow.com/questions/1486476/json-stringify-changes-time-of-date-because-of-utc/1486612#1486612)) is wrong. – RobG May 11 '17 at 22:46
  • In my case, adding the Z allows for consistent behavior across different devices, therefore allowing me to apply time zone adjustments without worrying about whether a device will have a differently parsed date. – edoreld May 12 '17 at 12:26
0

Diff in your date is because of timezone. You can try to convert date to UTC date for get perfect result like this.

    myDate = "2017-05-12T09:00:00";
    dateFoo = new Date(myDate).toUTCString();
Jay
  • 703
  • 9
  • 21