Invalid Date in Safari

Invalid date in safari

The pattern yyyy-MM-dd isn't an officially supported format for Date constructor. Firefox seems to support it, but don't count on other browsers doing the same.

Here are some supported strings:

• MM-dd-yyyy
• yyyy/MM/dd
• MM/dd/yyyy
• MMMM dd, yyyy
• MMM dd, yyyy

DateJS seems like a good library for parsing non standard date formats.

Edit: just checked ECMA-262 standard. Quoting from section 15.9.1.15:

Date Time String Format

ECMAScript defines a string
interchange format for date-times
based upon a simplification of the ISO
8601 Extended Format. The format is
as follows: YYYY-MM-DDTHH:mm:ss.sssZ
Where the fields are as follows:

• YYYY is the decimal digits of the year in the Gregorian calendar.
• "-" (hyphon) appears literally twice in the string.
• MM is the month of the year from 01 (January) to 12 (December).
• DD is the day of the month from 01 to 31.
• "T" appears literally in the string, to indicate the beginning of
  the time element.
• HH is the number of complete hours that have passed since midnight as two
  decimal digits.
• ":" (colon) appears literally twice in the string.
• mm is the number of complete minutes since the start of the hour as
  two decimal digits.
• ss is the number of complete seconds since the start of the minute
  as two decimal digits.
• "." (dot) appears literally in the string.
• sss is the number of complete milliseconds since the start of the
  second as three decimal digits. Both
  the "." and the milliseconds field may
  be omitted.
• Z is the time zone offset specified as "Z" (for UTC) or either "+" or "-"
  followed by a time expression hh:mm

This format includes date-only forms:

• YYYY
• YYYY-MM
• YYYY-MM-DD

It also includes time-only forms with
an optional time zone offset appended:

• THH:mm
• THH:mm:ss
• THH:mm:ss.sss

Also included are "date-times" which
may be any combination of the above.

So, it seems that YYYY-MM-DD is included in the standard, but for some reason, Safari doesn't support it.

Update: after looking at datejs documentation, using it, your problem should be solved using code like this:

var myDate1 = Date.parseExact("29-11-2010", "dd-MM-yyyy");
var myDate2 = Date.parseExact("11-29-2010", "MM-dd-yyyy");
var myDate3 = Date.parseExact("2010-11-29", "yyyy-MM-dd");
var myDate4 = Date.parseExact("2010-29-11", "yyyy-dd-MM");

Why does the safari date field appear as invalid date?

Safari has some major differences in the way it treats datetimes.

You can bypass them by just using the moment library.

You can find documentation here: https://momentjs.com/

moment works on safari as well as all other common and current browsers.

date-fns returns invalid date on safari

I see two issues:

1. You're relying on a nonstandard input format the first time you parse the date.

2. You're passing a Date into the Date constructor, which forces it to convert the date to a string, then parse the string.

I'd only parse it once, and use the standard date/time format when calling new Date the first time:

import { format, formatDistance } from "date-fns";

var date = new Date("2019-03-06T00:00:00");
// Note -----------------------^
console.log(format(date, "dd MMM, y"));
// No `new Date`   ^

Note that your string will be parsed as local time (on spec-compliant JavaScript engines¹) because it includes the time portion of the string. Unfortunately this varied after the format was added in ES2015, updated in ES2016, but where it's ended up is:

When the UTC offset representation is absent, date-only forms are interpreted as a UTC time and date-time forms are interpreted as a local time.

Since your string doesn't have a UTC offset (no Z or +00:00 or similar), and does have a time, it's parsed in local time. (Again, on spec-compliant JavaScript engines¹).

My recommendation is either don't parse date strings with the built-in Date object, or make sure you always have a timezone indicator on the string if you do.

---

¹ RobG pointed out that Safari parses new Date("2019-03-06T00:00:00") as UTC. Sadly, this is a bug in JavaScriptCore, Apple's JavaScript engine. It affects not only Safari, but Chrome on iOS as well (and probably any other iOS browser; I've tested Brave, Opera, and Dolphin), since Chrome has to use JavaScriptCore instead of its usual V8 on iOS because apps can't allocate executable memory, so JIT engines can't be used on iOS. But the V8 team have made an interpreter-only version of V8, so maybe Chrome (and Brave) on iOS will be updated to use that if it's fast enough.

---

Related Topics