This would enable us to mostly remove our Duration and simply focus on the operations of the arithmetic type with the overflow canarying we want to use for its Rep.

Special integer value to represent infinity.

Detect and absorb overflow on arithmetic operations.

Gain access to stdlib-quality implementations of time-related functions and operators.

Retain mongo names for the Duration types.

Eliminate friction between stdlib APIs and our code.

Captured from Slack discussion about C++20 support (PM-3140).

I like Howard Hinnant's idea of using a custom numeric type and otherwise making our duration types aliases to some std::chrono::duration<SafeRep,Period> directly. I've considered the same solution, but thought it wasn't allowed because of this misleading cppreference language:

"rep: an arithmetic type representing the number of ticks"
https://en.cppreference.com/w/cpp/chrono/duration

Which would disqualify custom numeric types. What the standard actually has said since C++11 is:

"rep: An arithmetic type or a class emulating an arithmetic type"
https://eel.is/c++draft/time.clock.req#tab:time.clock

And the requirements on that type are spelled out.

namespace mongo {

// Numeric interface. But deal with overflows and infinity sentinel.
class ChronoRep {
    ...
};

template <typename Period>
using Duration = std::chrono::duration<ChronoRep, Period>;

using Milliseconds = Duration<std::milli>;  // etc
...

} // namespace mongo

}

(SERVER-71206) inspired this idea. We would not have to fix little std::chrono::duration vs mongo::Duration divergences like that anymore, as we would be using std::chrono::duration.