What's the behavior of date arithmetic around epagomenal days?

[Manishearth]

The Coptic and Ethiopian calendars are solar calendars following the Julian cycle, but they have 12 normal months of 30 days each, and they intercalate with 5/6 epagomenal days inserted after month 12 (I'm going to call it "December" here for convenience).

This 13th month is sometimes termed a "short" month, with many analyses seeming to treat it as not actually being a month.

What should happen to date arithmetic involving months around this period? For example, should subtracting December 1 from January 1 produce 1 month or 2? What about adding 1 month to December 1: should it be January 1 or Epagomenal 1?

Internally, the distinction seems to be whether the epagomenal days should be treated as belonging to an additional month, or just extra days on December that get formatted as an additional month.

I suspect the answer to this question may involve user research.

cc @ryzokuken

[justingrant]

5/6 epagomenal days inserted after month 12 (I'm going to call it "December" here for convenience) every few years.

My understanding is that those days are added to every year: 5 on normal years, 6 on leap years. Is that what you meant?

What should happen to date arithmetic involving months around this period? For example, should subtracting December 1 from January 1 produce 1 month or 2? What about adding 1 month to December 1: should it be January 1 or Epagomenal 1?

Temporal currently assumes that those extra days are (not just "formatted as") a 13th month. So currently the answers to your questions are "2 months" and "Nissieh 1" (first day of the intercalary month).

It's implemented that way because when doing the research for the current polyfill implementation, I only found sources referring to it as a 13th month. I have not seen any sources that consider the intercalary month to be part of the 12th month for arithmetic or any other purpose. Could you share them? Note that I'm not claiming to be an expert on this, only that I was unable to find any English-language sources that implied that those days were considered to be part of the 12th month.

I agree that it makes sense to gather more user data. Who owns doing this gathering? IMHO it's not Temporal; we're the user-facing API but the underlying intelligence about calendar behavior comes from ICU lower in the stack. We just do what we're told. 😄

One thing that would may sense would be to see what other platforms do. Neither Java nor .NET support Coptic or Ethiopic calendars. But...

• iOS has a Calendar type that supports those calendars, and it has a dateByAddingUnit method that can add a month. So someone who knows how to write ObjectiveC could probably whip up a quick test.
• Android has: a CopticCalendar type. This type has a fieldDifference method.

In absence of other guidance I'd be inclined to follow what iOS and Android are doing, if only for compatibility reasons.

[ryzokuken]

Thanks for raising this @Manishearth! My first instinct here is to concur with @justingrant's suggestion, that makes a lot of sense. Atleast in the case of Android, I believe this calendar math comes from ICU, so I could take a quick look into what the ICU code says.

[justingrant]

BTW, If we do choose to ignore the 13th month for arithmetic purposes, this has interesting implications that we'd need to think through as it might potentially affect the Temporal API and/or guidance for developers. For example, many calendar UIs have a "month scroller" where you click a "next" button and it advances to the next month using addition. Would those UIs break in Coptic?

My general concern is that most developers will only write and test their code in ISO. Whenever we deviate from ISO behavior (e.g. if arithmetic doesn't match monthsInYear or daysInMonth) then we increase the % of real-world code that won't work in non-ISO calendars. Therefore, adding a new deviation from ISO should be a last resort when we're sure that local custom requires it. If it's on the fence, then IMHO we should match ISO behavior because doing that will lead to more code being usable as-is in non-ISO calendars.

[Manishearth]

My understanding is that those days are added to every year: 5 on normal years, 6 on leap years. Is that what you meant?

Yep sorry. I realized this while researching the issue but forgot to update the text.

I have not seen any sources that consider the intercalary month to be part of the 12th month for arithmetic or any other purpose.

You misunderstand, I'm saying that it's an equivalent mental model, not that it's the one people hold. The one some people do seem to hold is that those 6 days do not really form a part of any month.

In my experience sources talk about ambiguity in whether this is considered a 13th month, I don't recall better sources but at least Wikipedia mentions "sometimes reckoned as their thirteenth month".

But I guess in a case of "sometimes" we probably can still pick one way, and treating it as an extra month does seem consistent.

[Manishearth]

I agree that it makes sense to gather more user data. Who owns doing this gathering? IMHO it's not Temporal; we're the user-facing API but the underlying intelligence about calendar behavior comes from ICU lower in the stack. We just do what we're told. smile

I disagree: I think there are a lot of such choices involved in Temporal and they need to be documented, it can't just be "do what ICU does", that's not a complete specification, and ICU typically does not document its choices here, nor does it make any guarantees: such a spec would essentially be pinning us to ICU.

[justingrant]

But I guess in a case of "sometimes" we probably can still pick one way, and treating it as an extra month does seem consistent.

Sounds good. IMHO, as a general principle for cases where there are multiple possible interpretations, I think it makes the most sense to favor the ISO-like behavior because doing so makes it more likely that code will "just work" in non-ISO calendars. IMHO the bar for divergence should be "the majority does it this way in that calendar" not just "some people do it this way". In cases where there's not a clear winner, then the preference should be for ISO-like behavior, especially when it'd introduce a net-new inconsistency from ISO that doesn't exist in any other ICU calendar.

What do you think?

I disagree: I think there are a lot of such choices involved in Temporal and they need to be documented, it can't just be "do what ICU does",

Yep, I agree with you too, I didn't say it well. I should have been clearer: non-ISO calendars don't exist in the 262 spec so Temporal defers all non-ISO behavior questions to 402, which (currently) defers these questions to ICU. I think it'd be great for 402 to include more of the specification of calendar behavior. I was mostly talking about whether it's TG2 folks or Temporal champions who should be driving the research behind these spec changes. I think it's probably best to be the former because folks working on 402 are more likely to have the existing contacts and processes to successfully conduct this research.

[Manishearth]

What do you think?

Agreed.

I was mostly talking about whether it's TG2 folks or Temporal champions who should be driving the research behind these spec change

Ah fair.

[ptomato]

I'd like to move this over to the ecma402 repo, as it's a question that needs to be answered but is not going to be specified in Temporal.