Stage 2.7 review: Be more specific about [[DaysInWeek]]

[Manishearth]

The spec currently says The number of days in the date's week. for [[DaysInWeek]].

What are the situations where this number will not be 7? Is this intended to encompass a wider notion of "week" that can cover things like the multiple "weeks" in the Javanese calendar, or the 10-day cycles in the French republican calendar? If so, we should be specific, since in a calendrical concept by default "week" means the regular 7-day week. The spec also very much assumes that weeks in Durations are just sugar for 7 days.

Perhaps we should standardize this to the number 7.

[sffc]

I agree, since we're working with a closed set of calendars, we can use 7, and if we were to ever add a non-7-day-in-week calendar, we can revisit that assumption.

[sffc]

Also, it might be better to add this as a whole other unit, instead of using the "week" terminology. Some calendars, including Chinese, used various types of alternative divisions. There is a system for calculating 60-day cycles with 10-day subdivisions called "Xún" (旬), but Chinese has a different word for week, "Xīngqí" (星期).

I recall that some other calendars have other various periods that lie somewhere between a day and a month, and they have a whole bunch of other quirks, like not necessarily being a consistent length. I love to point at the Hawaiian lunar calendar that had week-like periods of either 9 or 10 days in order to evenly divide the months that were either 29 or 30 days.

[Manishearth]

Right, plenty of calendars have an additional layer of potentially-unaligned cycles between months and days, but it is not common to use the term "week" on its own to refer to them.

If we wish to support these I would recommend having an API that has week codes that let one select ISO week, French republican week, Hawaiian lunar week, or the multiple Javanese weeks. The fact that the Javanese calendar has a week cycle, a 5-day cycle, and a 210-day cycle which all are used concurrently is a sign that having a single API is not the best route forward.

[ptomato]

The spec also very much assumes that weeks in Durations are just sugar for 7 days.

Where did you see this? This assumption exists in a few places, but it should only be happening in the context of the ISO calendar.

[Manishearth]

@ptomato heh. In this open PR, turns out: #69, I was reviewing it yesterday so the assumption was fresh in my mind, I forgot that that was from a PR.

---

Though I think my position still holds. Temporal still only has one notion of week: [[DaysInWeek]] and other week-related things have no way of requesting different week kinds. This means that we are forced to pick a "primary" notion of week, per calendar.

"'week' refers to the 7 day week, always" is a defensible position to hold, and while it feels a bit 7-day-week-centric, to some extent that's just what that word means.

"'week' refers to a per-calendar concept and there is one primary notion of 'week' per calendar", is, IMO, not a defensible position: calendars with other week-like cycles often have multiple (sometimes including the 7 day week). As such I don't think we have any choice other than settling on the 7 day week here.

For example, the Chinese 旬 cycle is still somewhat a thing, but it would be against user expectations to treat it as a more primary notion of week over the 7-day cycle. The same goes for Javanese 5-day cycles.

If we had this discussion a couple years ago I would have perhaps suggested renaming all instances of "week" to "iso week" or something and leaving the semantic space open for a more robust day cycle API, but we're somewhat locked in to the "week" terminology now.

[ptomato]

The Wikipedia article on weeks has several historical examples of primary weeks that are not 7 days. It's unlikely to be relevant to the web, but on the other hand it costs us nothing to say something like "Let daysInWeek be the number of days in a week in calendar (7 for all currently supported calendars.)"

[Manishearth]

Yes, and that section starts with saying the definition is sometimes expanded, indicating it is not a default definition. That article was one of the things that actually led me to my conclusion here in the first place.

I think my point stands: most of the actual modern calendars with other week like notions have multiple such notions in use (including the 7 day week). If we seriously wish to support these, then we have the wrong API and we should go back to the drawing board. If we don't seriously wish to support these (except potentially leaving space for them), hardcoding the current API to 7 is cleaner. I don't think this middle ground where we make partial allowances for the existence of non-7-day-weeks but have an API that will not work for them is a good place to be. What is the point of those allowances if they cannot be used?

[sffc]

I don't think what we do here will have a very big impact on how we end up supporting these week-like periods in the future. It's just moving words around, which we can do and undo.

[Manishearth]

Right.

I still think we should hardcode it to 7, but if not can we specify that it is a per calendar constant? I think having it be completely unspecified isn't the best regardless of how we're planning on future proofing it.

If it's a constant then the arithmetic spec/code becomes easier to reason about. Otherwise it can complicate things.

[ptomato]

Isn't that essentially what I suggested above?

[Manishearth]

@ptomato I was hoping that the fact that it is a constant would be normative and not implementation-defined. But yes.

[sffc]

Here's the language I'm currently using in #69.

Let _daysInWeek_ be 7 (the number of days in a week for all supported calendars).

So it is a spec-defined fixed value but still retains commentary about where it came from.