7

I feel like I am missing something here.

The Date.getDay() method is supposed to return a value from 0-6. 0 for Sunday and 6 for Saturday.

Now I have two dates, both are 'Sunday' which should return 0. 

new Date('1990-11-11').getDay() // returns 6 
new Date('2016-1-3').getDay() // returns 0

What is causing the discrepancy? I dare to question the validity of the .getDay() method, but I can't figure out what is going on.

EDIT

> new Date('1990-11-11')
Sat Nov 10 1990 17:00:00 GMT-0700 (MST)
> new Date('2016-01-03')
Sat Jan 02 2016 17:00:00 GMT-0700 (MST)
> new Date('2016-1-3')    // they say this format is wrong, but it returns the right date
Sun Jan 03 2016 00:00:00 GMT-0700 (MST)

I don't understand what is going on. January 3rd is Sunday and November 11th 1990 is Sunday. Why is it saying Saturday?

Rob Lyndon
  • 12,089
  • 5
  • 49
  • 74
mattdevio
  • 2,319
  • 1
  • 14
  • 28

3 Answers3

3

The one that is wrong is the one that returns Sunday, and that must be because the format is incorrect. 1990-11-11 is interpreted as 00:00:00 on midnight of the 11th, UTC, which is 5pm on Saturday the 10th in your time zone.

If you use getUTCDay(), you should get 0 for both dates.

new Date('1990-11-11').getUTCDay() // returns 0
new Date('2016-01-03').getUTCDay() // returns 0
Rob Lyndon
  • 12,089
  • 5
  • 49
  • 74
  • I totally agree with this answer. Obviously the `2016-1-3` is not in ISO format. You would think that invalid formats would throw errors, but I guess thats just javascript. Using the getUTCDay() returns the correct values. Man now I can go to sleep. Thanks everyone! – mattdevio Dec 28 '16 at 10:17
  • @magreenberg—there is only one "valid" format. Implementations are free to do whatever they wish with anything that is non–conforming. – RobG Dec 28 '16 at 23:38
2

Certainly, your claim that 1990-11-11 is Sunday is true but you have to understand that JavaScript Date object:

  • Handles time as well as date
  • Is time zone aware
  • Is poorly designed and rather counter-intuitive

Your own tests illustrate this:

new Date('1990-11-11').getDay() // returns 6 
> new Date('1990-11-11')
Sat Nov 10 1990 17:00:00 GMT-0700 (MST)

What happens is that constructor assumes local time or UTC depending on the syntax used:

Note: Where Date is called as a constructor with more than one argument, the specifed arguments represent local time. If UTC is desired, use new Date(Date.UTC(...)) with the same arguments.

Note: parsing of date strings with the Date constructor (and Date.parse, they are equivalent) 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.

... and your syntax makes it as UTC. But many others methods assume local time:

The getDay() method returns the day of the week for the specified date according to local time, where 0 represents Sunday.

Álvaro González
  • 142,137
  • 41
  • 261
  • 360
  • I think this answer describes what is going on the best. Thanks Alvaro. – mattdevio Dec 28 '16 at 10:36
  • The design does seem clunky and user-unfriendly, but in fairness, dates are intrinsically complex. You don't fully appreciate this until you start working with use cases in detail, and in diverse locations with differing daylight savings conventions. The JS implementation is logically consistent, for all its apparent strangeness. As with so much software, the key is trying to get into the mind of the developer. – Rob Lyndon Dec 28 '16 at 11:42
  • 1
    @RobLyndon JavaScript date handling is indeed pretty comprehensive and robust but the API is extremely confusing (and that's what I meant when I complained about the design). I mean... Zero-based months? Constructor with three different signatures most of which behave differently depending on the format of values and the browser configuration? `getFullYear()` being added to fix Y2K issues? – Álvaro González Dec 28 '16 at 11:51
  • Yes, zero-based months is pretty crazy. I have to concede that. – Rob Lyndon Dec 28 '16 at 11:54
  • @ÁlvaroGonzález—having zero–based months is no different to zero–based days. They aren't intended for display to humans but are very handy for programers. ;-) The javascript Date object is a very simple object, it just has a time value. However, date arithmetic is intrinsically complex and parsing of strings should never be left to the constructor (or Date.parse). – RobG Dec 28 '16 at 23:46
0

getDay returns day index (from 0 to 6), where 0 is Sunday. https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Date/getDay

Return value: An integer number corresponding to the day of the week for the given date, according to local time: 0 for Sunday, 1 for Monday, 2 for Tuesday, and so on.

Update: new Date constructor returns different time values for those dates.

new Date('2016-1-3') ==> Sun Jan 03 2016 00:00:00 GMT+0100 (CET)

new Date('1990-11-11') ==> Sun Nov 11 1990 01:00:00 GMT+0100 (CET)

And for some reason, the first one gets interpreted as Saturday on your machine. Sorry for not being able to help out more

Update2:

Using two digits for month/day should standardize the results. Example:

(new Date('2016-01-03')).getDay() ==> 0

getDay