2

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(["2014","01","01"]) is giving me output Wed Jan 01 2014 00:00:00 GMT-1200 (GMT-12:00).

new Date("2014-01-01") is giving me output Tue Dec 31 2013 12:00:00 GMT-1200 (GMT-12:00).

Why this is happening? Shouldn't ["2014","01","01"] and "2014-01-01" suppose to give same output?

Shakibuz_Zaman
  • 260
  • 1
  • 14

3 Answers3

5

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.

    new Date(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:

    new Date(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.

Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575
4

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.

Sebastian
  • 111
  • 3
  • So you are telling that in ```new Date(["2014","01","01"])```, javascript don't apply timezone? – Shakibuz_Zaman Aug 22 '19 at 02:52
  • 1
    `new Date(["2014","01","01"])` will create a date in the time zone you are at. Hence the result you are seeing of : `Wed Jan 01 2014 00:00:00 GMT-1200 (GMT-12:00)` but `new Date("2014-01-01")` will **first create the date as if you are in UTC** (using parse) **and then** 'apply' your time zone (-12hs) hence getting the second result you are seeing: `Tue Dec 31 2013 12:00:00 GMT-1200 (GMT-12:00)` – Sebastian Aug 22 '19 at 03:23
  • Thanks for your answer, but while close it is not quite correct. Time zones are applied when passing in local time, or outputing local time. They are not applied when passing in or outputing UTC - as the `Date` object is inherently UTC based. Also, arrays are not accepted by the `Date` constructor, or by `Date.UTC`. Or rather, it's not allowed by spec, but is implementation-specific behavior. See my answer. – Matt Johnson-Pint Aug 22 '19 at 17:09
  • The main take away here which related to the question from @Shakibuz_Zaman is that as mentioned in my answer when you pass in a date only string the date will be considered as UTC based and when you use the other constructors to individually assign the different date parts (year, month, day, etc) the date instance is created based on the local time where the code is running. – Sebastian Aug 22 '19 at 21:15
0

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.

tripleplayj
  • 94
  • 4