Dates have always been a nightmare for developers, specially when you have to face some kind of international scenario, which, on the other hand, is probably most of  the time 😀 .

Here I want to discuss a funny thing I discovered the other day while I was playing around with Date function in javascript, again.

Basically, it all reduces to how standard you are when instantiating a date using a string in javascript. But first, let me redirect you to the EcmaScript specifications. There, you can learn about the standards and what it is that we can expect from our browsers when dealing with dates.

It seems that when you use new Date() constructor and you use a string as a parameter, Date.parse() is used internally (new Date(value),

Here you are a little excerpt of how this method should work according to standards (Date.parse (string),

The parse function applies the ToString operator to its argument and interprets the resulting String as a date and time; it returns a Number, the UTC time value corresponding to the date and time. The String may be interpreted as a local time, a UTC time, or a time in some other time zone, depending on the contents of the String. The function first attempts to parse the format of the String according to the rules called out in Date Time String Format ( If the String does not conform to that format the function may fall back to any implementation-specific heuristics or implementation-specific date formats. Unrecognisable Strings or dates containing illegal element values in the format String shall cause Date.parse to return NaN.


So, as you can read above, the Date.parse function falls back to Date Time String Format specified in Date.parse (string),

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 […]

Date Time String Format

Making it short, if the string you pass as a parameter to the Date constructor or the Date.parse() function is not an ISO date then each browser has the freedom to create its own implementation.

So far so good. But the problem comes when you stick to the Date Time String Format and some browsers decide they won’t work as you may expect. Surprisingly, IE11 and Firefox seem to work oddly when you omit the time zone offset. But, even more surprising is that IE9 seems to work according to the standards!!

Both IE11 and Firefox seem to have decided that whenever the time zone offset is not specified they will use the local time zone as default even when the EcmaScript specifications are very clear about this:

[…] The value of an absent time zone offset is “Z” […].

Date Time String Format

What has happened here? Why Internet Explorer has decided to join Firefox implementation against what Ecmascript specifications suggests when previous versions of this browser were implementing it right? Why Mozilla claims to be following the standards in his website when all seems to be leading to the opposite conclusion? Maybe I’m missing something but I’ve not been able to find any insight on this matter in the internet so these questions will remain unanswered until some of you who know of the dark secrets of the internet explain to me what’s behind these weird decisions.

In conclusion, it seems that Safari behaves as if the ISO date string without time zone was not standard and returns NaN and Firefox and IE11 have decided that they assume local time zone instead of Zulu time (GMT), hence getting a different result. If you want all modern browsers to behave the same way you should use full Date Time String Format, specifiying the time zone offset!

If you really need your dates to work as Firefox works without time zone offset (i.e. using local time zone offset) then you should consider using other Date constructor overloads.

Here you can see a simple live example. You can try this url in different browsers to check how they behave:

Date implementation

And here some screenshots in different browsers if you’re feeling lazy and don’t want to try it for yourself: