This seems to be related to the pending motions. There is no class "month" in the current working draft.

The "Euclidean division" description is repeated in the description of std::chrono::weekday, and any fix should be applied there too.

I'm kind of fond of the specification in terms of Euclidean division. I believe it says precisely what we want it to say. However your point about overflow is well taken.

One possible solution is to add to [time.cal.general] something along the lines of:

Any calendrical computation that would result in a value that is outside of the
range [year::min()/January/1, year::max()/December/31] has an unspecified result.

That's probably not exactly right. But something in that direction...

@HowardHinnant, what exactly do you fear will be lost when we talk about "reduced modulo y" instead? That seems to be fully equivalent, and one could argue that explicitly specifying "Euclidian division" might actually be overspecification (it's purporting to prescribe an algorithm, not a result.)

I see two problems:

1. "reduced modulo 12" doesn't result in a number in the range [1, 12].

2. I fear that "reduced modulo 12" will be coded as n % 12 which gives the wrong answer when n < 0.

I'm using this terminology for modulo and it must give a result in the range [0, 11] for negative and non-negative n. Floored division would work just as well as Euclidean division. But truncated division (which is what the C++ % operator does) gives the wrong answer for negative n.

@HowardHinnant, thanks for your thoughts. I believe we very carefully use English, not C++ code, to describe the modulo operation here, which is thus clearly highlighted as a mathematical operation, not a C++ operation. All we're doing is getting the canonical representative for the equivalence class, and we clearly say these are defined to be in [1,12] in our case.
Regarding your second concern, such an implementation would clearly violate any conceivable specification of the semantics (and the standard is not a tutorial), so I disagree we need the verbose description for that purpose.

I'm happy for the LWG to explore alternative wording, and to help review said wording. The most important thing for me is that vendors know what to provide and that customers understand what they are getting.

I would prefer that this change not be done editorially, but through a LWG issue so that it benefits from a full review of the LWG.

Perhaps something like:

Returns: a month with m_ equal to an integer in [1,12] that is congruent to the sum of unsigned{x} and y.count() modulo 12.

I think that should completely avoid the "number between 0 and 11" interpretation.

Just some food for thought for the LWG discussion.