Inconsistent behavior of JavaScript Date() function in iOS

Question

I use the Date() function to convert MySQL Date to the JS Date object. Following is the code of how I was doing it:

var a = "2019-03-12 12:30:03"; //MySQL Date

function MySQLToDate(dateString) {
   if (typeof dateString === 'string') {
      return new Date(dateString);
   }
   else {
      return dateString; //in case the argument is already an object
   }
}

alert(MySQLToDate(a));
//iOS Output: Invalid Date
//Normal Output: Tue Mar 12 2019 12:30:03 GMT+0530 (India Standard Time)

It was working absolutely fine as expected until I tested it in iPad browsers.

It returns Invalid Date in iOS. And of course, using the prototype function of Date() like getDate(), getMonth() etc return Nan.

So to overcome this situation, I researched and in one of the answers, I found out that passing the MySQL date directly into the JS Date function is a wrong practice. [Source]

Now my code looks like following:

var a = "2019-03-12 12:30:03"; //MySQL Date

function MySQLToDate(dateString) {
   if (typeof dateString === 'string') {
      return new Date(dateString.replace(" ","T"));
   } 
   else {
       return dateString; //in case the argument is already an object
   }
}

alert(MySQLToDate(a));
//iOS Output: Tue Mar 12 2019 18:00:03 GMT+0530 (India Standard Time)
//Normal Output: Tue Mar 12 2019 12:30:03 GMT+0530 (India Standard Time)

This solution is not giving an Invalid Date Error but literally gives an Invalid Date.

I also tried splitting the MySQL date and passing year, month, date, hours, minutes, seconds into the Date() but the time in the object is still wrong.

Your answers are most welcome.

@RK_15 That's the same question to whose answer (accepted one) I've gave credit in my question. That answer will give you a wrong date time rather than an Invalid Date. — TheCleverIdiot, Mar 15 '19 at 05:45
"2019-03-12 12:30:03" is not a format supported by ECMA-262, so parsing is implementation dependent. Apple browsers typically return an invalid date. "2019-03-12T12:30:03" should be parsed as local, but Apple browsers parse it as UTC. When manually parsing, remember to subtract 1 from the month. — RobG, Mar 15 '19 at 22:11

RK_15 · Accepted Answer · 2019-03-16T07:31:33.110

1

You can split the string and then use the Date's constructor:

// Use this constructor
    new Date(year, month, day, hours, minutes, seconds, milliseconds)

// code goes like this
    let tokens = "2019-03-12 12:30:03".split(/[-: ]/g)
    let date = new Date(tokens[0], parseInt(tokens[1]) -1, tokens[2], tokens[3], tokens[4], tokens[5]);
    console.log(date);

This solution is working in safari, chrome and firefox browser.

edited Mar 16 '19 at 07:31

answered Mar 15 '19 at 06:05

RK_15

929
5
11

1

That should be `new Date(tokens[0], tokens[1] - 1, ...)` and the bits aren'r really tokens, they're substrings. ;-) – RobG Mar 15 '19 at 22:07
I have corrected it – RK_15 Mar 16 '19 at 07:37

score 1 · Answer 2 · answered Mar 15 '19 at 14:00

1

The "invalid" time you're getting looks a lot like a "double" IST timezone date. IST = India Standard Time is 5.5 hours (5 hours 30 minutes) ahead of Greenwich Mean Time (GMT+5.5).

When parsing/replacing the 'T' in your date, make sure to add a 'Z' on the end, to indicate Zulu time. Zulu time is timezone independent (UTC).

return new Date(dateString.replace(" ","T") + "Z");

Not sure if the iPad is choosing a timezone by itself or not, but either way you're not specifying any Timezone, so you leave it open for it's own interpretation and liking.

answered Mar 15 '19 at 14:00

Ramon

1,415
9
18

2

This seems more like a comment than an answer. Apple browsers parse ISO 8601 formatted timestamps without a timezone as UTC (which is inconsistent with ISO 8601 and ECMA-262). Adding "Z" will change the timestamp from local to UTC in all implementations. – RobG Mar 15 '19 at 22:15
Thanks, @RobG and @Ramon, I tried this one without adding T and Z but made a slight change which is `return new Date(dateString.replace(/-/g, '/'));`. It's working absolutely fine for multiple timezones. – TheCleverIdiot Mar 16 '19 at 07:01
@RJ—that is a terrible solution as it changes the format to one not supported by ECMA-262 meaning results are implementation dependent. It's likely to fail at some point, you just haven't discovered when yet. [*RK_15's answer*](https://stackoverflow.com/a/55176524/257182) is a much better solution as it's standards compliant. – RobG Mar 16 '19 at 21:58

Inconsistent behavior of JavaScript Date() function in iOS

2 Answers2