Ambiguous Behavior Of Javascript New Date() Constructor For Same Different Formatted String

My local time zone is (UTC+06:00) Dhaka. In my own time zone I didn't find this problem. But changing the time zone to (UTC -12:00) International Date Line West in my pc, new Date

Solution 1:

This is due to new Date("2014-01-01") being created through the Date parse which considers this date to be UTC and then apply the timezone but new Date(["2014","01","01"]) is treated as literal values for each of the parameters in the constructor for your timezone. Although as mentioned in one of the comments below the format new Date(["2014","01","01"]) does not conform to RFC and hence provides different results depending on the browser.

from: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date

Note: Parsing of date strings with the Date constructor (and Date.parse(), which works the same way) is strongly discouraged due to browser differences and inconsistencies. Support for RFC 2822 format strings is by convention only. Support for ISO 8601 formats differs in that date-only strings (e.g. "1970-01-01") are treated as UTC, not local.

Perhaps what you are after is new Date(Date.UTC(2014,01,01));Date.UTC in order to create a consistent date that is not bound to the user's configuration.

Solution 2:

A few things:

• The Date constructor does not accept an array. See the specification, and the MDN docs. Any such allowance is implementation-specific. For example, new Date(["2014","01","01"]) will work in Chrome because the Chrome authors decided to allow it, but in Edge it gives an Invalid Date because it is not required by the specification. (The same applies to Date.UTC(array).)

• If you have separate date parts, you should pass them directly into the constructor. Note that in this form of the constructor, the months range from 0 to 11, so you must subtract one from the second parameter.

  newDate(2014, 0, 1)
  

• When you use the above form, the parameters are intended to be in terms of local time - that is, the time zone that is set for the environment where the code executes (the user's time zone in a browser environment, or the server's time zone in a Node.js environment). The time parameters (hour, minute, second, millisecond) default to 0, so this is midnight in the local time zone, or 2014-01-01T00:00:00.000.

• If you intended to pass UTC-based parameters, use the Date.UTC function, and pass the result back to the Date constructor, as in:

  newDate(Date.UTC(2014, 0, 1))
  

  This sets the date object to midnight UTC, or 2014-01-01T00:00:00.000Z.

• When you pass a string to the date constructor, it is first attempted to be parsed according to rules defined in the specification. If it cannot be parsed by the specification's rules, then it may be parsed in an implementation-specific manner.

  The specification defines that a string in YYYY-MM-DD format (without any time portion) is to be parsed as UTC. This deviates from ISO-8601, and is why you are seeing different results when you call new Date("2014-01-01"). It is interpreted as if you passed 2014-01-01T00:00:00.000Z (UTC).

• The Date object itself tracks only one single value, which is the number of milliseconds since the Unix epoch, which is 1970-01-01T00:00:00.000Z (UTC). You can see this value by calling .valueOf() or .getTime(). Thus when you parse with any form that is treated as local time, then a conversion happens at the time of parsing, from local time to UTC.

• Later, when you do anything that expects local time output, such as calling .toString(), or using functions like .getDate(), .getHours(), etc., another conversion from the internal UTC-based timestamp to local time is performed.

• In some environments, you will also see the conversion happen when you console.log a Date object, as if you called .toString(). In others, you will see the UTC-based output as if you called .toISOString(). The console output is implementation-specific.

Solution 3:

Notice that GMT time is -1200. When you are specifying the date, I believe it starts at midnight of that day. Since you stated 2014-01-01, it subtracted 12 hours from midnight on that day, giving you 2013-12-31 at 12:00PM.