[NAD] Predefined durations cannot hold full `year_month` range

[tomaszkam]

Orginal comment:

microseconds 62 bits (used to be 55) milliseconds 52 bits (used to be 45) seconds 42 bits (used to be 35) minutes 37 bits (used to be 29) hours 31 bits (used to be 23) days 26 bits (used to be 25) weeks 23 bits (used to be 22) months 21 bits (used to be 20) years 17 bits (used to be 17)

E-mail thread

[isocpp-lib] year_month arithmetic

[tomaszkam]

Tim's Song comment:

2. This is more theoretical: months is only guaranteed to be capable of representing ~+/-43690 years (2^19 - 1 months), but the difference between two year_months can be up to 65534 years + 255 months. I wonder if we should increase the bit count by 1 in the duration typedefs to guarantee that they are capable of representing the difference between two (possibly partial) dates that the calendar part of the library supports?

[tomaszkam]

Howard's full comment:

This sounds like a good idea to me. To be consistent across all of the predefined durations we should do:

microseconds 62 bits (used to be 55) milliseconds 52 bits (used to be 45) seconds 42 bits (used to be 35) minutes 37 bits (used to be 29) hours 31 bits (used to be 23) days 26 bits (used to be 25) weeks 23 bits (used to be 22) months 21 bits (used to be 20) years 17 bits (used to be 17)

Notes:

• nanoseconds maxes out at 64 bits and can’t be helped (+/-292 year range).

• years remains purposefully unchanged.

• The change to minutes will break 32 bit libc++ and VS, as on these platforms it changes minutes::rep from 32 to 64 bits. If that’s unacceptable, I completely understand and would not recommend pushing against the vendor’s will. But even if we keep minutes as is, I believe we can make the changes everywhere else. I would like to get feedback from vendors on this one.

[HowardHinnant]

Close. This is an ABI break for some platforms, and too big of a deal for C++20 at this stage. The cost would outweigh the benefit.