Is `daysInMonth` the count of all days or the number of the last day?

[justingrant]

Days can be skipped, either by calendars (e.g. Julian-to-Gregorian transition) or by time zone changes (e.g. Samoa's 2011 change to the other side of the International Date Line.

How should daysInMonth be affected by these skipped days?

[ljharb]

I think I would assume that daysInMonth === days.length, where days is an array of every day in the month?

In fact, it might be a nice convenience API for a Calendar, or anything with a Year and a Month, to provide the equivalent of:

* days(month) {
  for (let i = 1; i <= daysInMonth; i += 1) {
    yield i;
  }
}

(i know this isn't accurate but it should convey the gist)

That way, nobody would be tempted to use daysInMonth to write a naive and incorrect implementation, when what they really want is the above, for a datepicker or similar.

[justingrant]

We discussed this issue in today's meeting. The consensus was that daysInMonth should be the number of the largest day of the month, because the other option (the count of actual days in the month) had problems:

• Days skipped by time zones are invisible to Temporal types other than ZonedDateTime, which would mean that PlainDate.prototype.daysInMonth would return a different value depending on the Temporal type used. That seems weird. Also, including TimeZone in the daysInMonth calculation would add complexity and performance overhead to handle a very rare case. However, it would also be confusing for developers if days skipped because of time zones were treated differently from days skipped because of calendars.
• daysInMonth is the current solution for the "what's the last day of this month?" use case. Given how rare it is to skip days (e.g. once in one time zone, and AFAIK never in the last 200 years in all ICU calendars) expanding the Temporal surface area to add a separate property for this rare case seems like a bad tradeoff.

Renaming this property (e.g. to lastDayOfMonth) might be a compromise option. We didn't discuss this in the meeting but I'd be open to it.

[ptomato]

I don't think we should rename it at this point unless the current name is really found to be problematic in delegate reviews.

Other than that, good summary, thanks!

[Louis-Aime]

I agree with all this. The Julian-to-Gregorian transition leads to very funny cases, like 1700 for most Protestant German states. This year of only 355 days was at the same time a leap year (in the beginning) and a common year (since 1 March). February had only 18 days (18 February was followed by 1 March). In reality, the "year" and the "month" are not the same before and after the transition. We switch from one calendar to another, which happen to share the same month names.

[Louis-Aime]

In the experimental development of a class of Western calendars, i.e. calendars that have a Julian-to-Gregorian transition date, I finally took the convention that daysInMonth is the number of days in a month, a similarly daysInYear the final number of days in the civil year, dayOfYear the rank of the current date since the first day of the same year.

This seems consistent with the names of the properties and other proposals like #729 ( transferred to Temporal.PlainYearMonth.atEndOfMonth method ).

Examples:

• In Rome, the year 1582 had only 355 days, and october 1582 had 21 days instead of 31.
• In several protestant states of Germany, 1700 had only 255 days. February 1700 had 18 days, and it happens that 18 Feb. was the eve of 1 March. In this year, 1 March was the 50th day of the year, not the 60th nor the 61th.
• In parts of Switzerland, 1701-01-12 was the first day of 1701. The eve was 31 Dec. 1700 (julian).

On the other hand, I make the week numbering system changes abruptly at the switching date. The current's week number is increased by one the day of switching. In 1701 in Switzerland, weeks are counted is if the year had begun on 1 Jan. This convention can be changed.

If well documented, theses cases should not be a problem. They remain exceptions.

[ptomato]

We should make a note about this in CalendarDateDaysInMonth (and maybe ISODaysInMonth)

[gibson042]

Is this not already covered by CalendarDateDaysInMonth (bold emphasis mine)?

It takes a date-like object date and returns the number of days in the given month in the calendar represented by calendar.

[justingrant]

@gibson042 per #1315 (comment), this definition creates some challenges. Using a definition of "1-based number of the last day of the month" might be a more developer-friendly definition. What do you think?

[gibson042]

That would be a normative change. The operation is specified to return the count of days, not the number associated with the last day (which would be discovered by a different approach, such as "constrain").