0

I have following trivial JS code:

document.getElementById ("testLastTime").innerHTML=new Date ('2020-07-01T11:59:45').toLocaleString()

On Chrome, Edge, Firefox (all on Windows) is shows correct date:

7/1/2020, 11:59:45 AM

However on iOS devices this date is interpreted as UTC and following date is shown (I am on PST):

7/1/2020 4:59:45 AM

This code is part of the larger project, where datetime ISO formated string in local time (without TZ) is send to client by the server (Python flask).

What should I do have JS on all devices show the same date?

leon
  • 1,412
  • 2
  • 17
  • 26
  • Possibly I can only think that the inconsistence may be down to the method toLocaleString() and not the browser. try toString() method or toDatestring() but format may be different and with toDatestring() i don't think you'll get the time portion. If you are going to do a lot of date manipulation, then I suggest looking at moment library – Chief Jul 01 '20 at 19:30
  • @Chief - the same result when using toString(). Interestingly on iOS the time is shown as correct TZ: GMT-0700(PDT) as Windows, yet with 7 hours offset – leon Jul 01 '20 at 19:38
  • Safari's parser is buggy. Don't use the built–in parser, see [*Why does Date.parse give incorrect results?*](https://stackoverflow.com/questions/2587345/why-does-date-parse-give-incorrect-results) – RobG Jul 01 '20 at 20:14
  • Just add an explicit timezone in the end, such as `new Date(…+'Z')` – Bergi Jul 01 '20 at 20:38
  • @Bergi I think I tried. I don’t think it helped. Anyway moment did the trick – leon Jul 01 '20 at 20:40

1 Answers1

0

as Chief has suggested using moment libary fixed the issue. Since I am using ChartJS, moment was loaded already.

so while this works:

document.getElementById ("testLastTime").innerHTML=new moment ('2020-07-01T11:59:45').format ('M/D/YYYY, h:mm:ss A');

I am still curious to understand why JS iOS results are in UTC, while PC results are not while using Date

leon
  • 1,412
  • 2
  • 17
  • 26
  • The format '2020-07-01T11:59:45' without a timezone should be treated as local ([*EMCA-262 §20.3.1.15*](http://ecma-international.org/ecma-262/10.0/#sec-date-time-string-format): "*When the time zone offset is absent, date-only forms are interpreted as a UTC time and date-time forms are interpreted as a local time.*"), but Safari's parser is buggy and treats it as UTC. – RobG Jul 01 '20 at 22:02
  • @RobG - yep, totally agree and this is how understand spec. Hence my original post. Without looking at the moment JS sources, it does appear moment is aware of this bug and working around it then? – leon Jul 01 '20 at 22:04
  • No, it isn't but does avoid it. If you don't pass the parse format to moment.js and the string is a format supported by ECMA-262, moment uses its own parser hence it avoids the issue. If the string is not one of the ISO formats recognised by ECMA-262, it will fall back to the built–in parser. You should **always** supply the parse format. – RobG Jul 02 '20 at 08:13