Define "day" as a solar day?

[sffc]

There are various different issues where we are increasingly making the assumption that a day is 24 hours long, like #307. Separately, the data model discussions in #290 suggest that we use the ISO calendar data model, in which days are solar days, not lunar days.

Some interesting cases to consider:

• In the traditional Hebrew calendar, days are solar, but they start at sunset and are variable lengths.
• In the Hawaiian Moon Calendar, days are defined based on the moon cycle, and multiple lunar days can fall on the same solar day. For example, something like "high tide" or "moonrise" could mark the beginning of the day.

As a way to work around this issue, we could define the term "day" to mean a solar day. Calendars can then create their own custom field to signify a more specific kind of day, like lunarDay. Furthermore, Calendars must obey days being 24 hours for the purposes of arithmetic.

[sffc]

Alternatively, we could choose to leave the definition of "day" as calendar-dependent. That's maybe also fine, but then we should scrub the API of anything that implicitly assumes that days are 24 hours.

Seconds (or JavaScripty milliseconds) are not a bad choice for a unit that is a constant length.

[sffc]

@gibson042 pointed out in #307 that the data model documentation states:

A Temporal.Date object represents a calendar date. This means there is no way to convert this to an absolute point in time, however combining with a Temporal.Time a Temporal.DateTime can be obtained

This suggests that we should leave the definition of "day" to be calendar-dependent.

If we do this, it's fine, but it means that we will definitely need to augment the Temporal.Date data model as discussed in #355.

[sffc]

Because of the data model agreed on in #290 and #391, and agreement to not move forward with #390, we are effectively defining Temporal.Date as representing a solar day, in the sense that the ISO calendar calibrates dates to align with the sun and not the moon.

[ljharb]

How does that affect the ability to represent the Hebrew calendar?

[sffc]

The traditional Hebrew calendar is not affected by this, since days are solar days (even though they start at sunset, they are still solar days).

[ljharb]

What calendars would then be impacted?

[sffc]

I updated the OP a bit.

The Hawaiian Lunar Calendar would be impacted, because it uses lunar days (based on moonrise), and lunar days are slightly shorter than solar days. However, a simple workaround for the Hawaiian Lunar Calendar is to use Temporal.DateTime for the purposes of representing lunar days.

[ljharb]

What’s the downside to having the length of a day be defined by the calendar?

[sffc]

tl;dr, because we agreed in #290 that the data model for Temporal.Date is based on the ISO calendar, which means that days are solar days. It took a while to reach the conclusion that this was the cleanest data model. It makes a lot of things easier and more intuitive, while not impacting any known modern-use calendars (the Hawaiian Moon Calendar doesn't even have a Wikipedia page that I can find; I only learned about it at a museum in Honolulu).

[ljharb]

Right, but what does it hurt to provide more hooks for future use cases? Mars days aren’t 24 hours long either :-)

[sffc]

I don't have a proposal for a data model proposal that supports Mars or Moon days without incurring significant cognitive burden or ergonomic costs on the Earth-based solar days that we currently support. If you have one, please make it. You can see the previous discussion in #290, #390, #391, and the Markdown files including calendar-draft.md and calendar-subclassing.md.