Issue with "Date.prototype.getMonth()": (short summary here please)

[arcanisgk]

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

What information was incorrect, unhelpful, or incomplete?

I suppose that for generations this has been working this way ... but I think that at some point it should be corrected.
when using and or creating the Date object

var now = new Date();

works correctly, but trying to extract information is where a multitude of concepts occurs:
first concept:
now.getFullYear()
get the current 4-digit year, work nice.

second concept:
now.getDate()
gets the day of the given date.

third concept:
now.getMonth()
**returns the position of the month starting from 0, what has happened with this concept, this is horrible ... if we follow the pattern of names I should get the number of the current month based / starting from 1 for January to 12 December ... This concept does not apply the same with days or years. **

I think that what is tried with this method was to obtain the position for which there should be a named method:

now.getMonthPosition()

over time a numerical patch had to be inserted to calculate the month correctly:

let mm = next.getMonth()+1;

[Andrew-Cottrell]

Fortunately, we will probably have proposal-temporal in the ECMAScript specification next year and then we can polyfill or shim it as required. In particular, Temporal.PlainDate, and other Temporal routines that accept and return month numbers, use one-indexed ISO month numbers. This should make date calculations much less error prone.

After that, I expect best practise will be to avoid Date for calculations and to convert as required.

[arcanisgk]

Fortunately, we will probably have proposal-temporal in the ECMAScript specification next year and then we can polyfill or shim it as required. In particular, Temporal.PlainDate, and other Temporal routines that accept and return month numbers, use one-indexed ISO month numbers. This should make date calculations much less error prone.

After that, I expect best practise will be to avoid Date for calculations and to convert as required.

Well, according to that new standard or development, it is still necessary:

• getYear(): Returns the year that the object indicates to 4 digits (2021).
• getYearShort(): Returns the year that the object indicates to 2 digits (21).
• getMonth(): Returns the month that indicates the object from 1 to 12. It can pass the argument "true" so that the returned value contains 0 in front for the dates from 01 to 09.
• getMonthPosition(): Returns the month that the object indicates from 0 to 11 (Integer), based on a matrix of 12 positions.
• getDay(): Returns the day indicated by the object. be able to pass the argument "true" so that the returned value contains 0 in front for the dates 01 to 09.

[Andrew-Cottrell]

Perhaps DateTimeFormat does what you want?

• getYear(): Returns the year that the object indicates to 4 digits (2021).

new Intl.DateTimeFormat("en-US", {year: "numeric"}).format(new Date);

• getYearShort(): Returns the year that the object indicates to 2 digits (21).

new Intl.DateTimeFormat("en-US", {year: "2-digit"}).format(new Date);

• getMonth(): Returns the month that indicates the object from 1 to 12. It can pass the argument "true" so that the returned value contains 0 in front for the dates from 01 to 09.

new Intl.DateTimeFormat("en-US", {month: "2-digit"}).format(new Date);

• getMonthPosition(): Returns the month that the object indicates from 0 to 11 (Integer), based on a matrix of 12 positions.

I'm unclear what a matrix of 12 positions refers to.

• getDay(): Returns the day indicated by the object. be able to pass the argument "true" so that the returned value contains 0 in front for the dates 01 to 09.

new Intl.DateTimeFormat("en-US", {day: "2-digit"}).format(new Date);

There is a polyfill for Intl.DateTimeFormat.

[sideshowbarker]

This issue doesn’t appear to be about how date.getMonth() is documented in MDN but instead is about how date.getMonth() was designed. As such, it’s out of scope for this issue tracker, which is for issues about specific problems in existing MDN articles, or for proposing new content for MDN articles.