search

tomaszkam / date

A date and time library based on the C++11/14/17 <chrono> header
Other
0 stars 0 forks source link

[NAD] Calendrical computation outside or years range #9

Closed tomaszkam closed 5 years ago

tomaszkam commented 5 years ago

Original comment:

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.

Suggestion:

We’re going to hit this all over the place. Perhaps a blanket statement in [time.cal.general] 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.

Email conversation (reflector): [isocpp-lib] year_month arithmetic

tomaszkam commented 5 years ago

It does not look like we can avoid undefined behavior in this case, without performing major change to the implementation of functions like: https://github.com/HowardHinnant/date/blob/ed0368fc75427ef05cefdf19a39b60d7bed2f039/include/date/date.h#L2150-L2153 Thus I think, we would need to make behavior of such arithmetic undefined.

tomaszkam commented 5 years ago

Tim's Song comment:

Additionally, the reference implementation is susceptible to integral overflow for very large values of dm, though the actual result in such cases will be outside the representable range of year_month anyway in all implementations that do not use 20-bit signed integers for months. I don't know if we want to make a "not UB" promise in this case. For comparison, month arithmetic will never have UB unless months::rep is at least as big as long long (see also https://github.com/cplusplus/draft/issues/1974).

HowardHinnant commented 5 years ago

I think we can close this. Yes, overflow is a problem. However it is an existing issue within the <chrono> library since C++11. The status-quo throughout <chrono> is to just let what happens happen. If we want to say something more chrono-wide, we should do it in C++23.

tomaszkam commented 5 years ago

Close it as the extension (EXT) or just not/no longer a defect (NAD)?

HowardHinnant commented 5 years ago

The LWG issues list has something called NAD-Future. It means there is a suggestion that we might revisit this issue for a future standard. Maybe that would be appropriate here.

tomaszkam commented 5 years ago

Ok, closed with NAD but added LWG-issues tag.