This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.

3091. subsecond-precision time_of_day and durations that seconds cannot convert to

Section: 30.9 [time.hms] Status: Resolved Submitter: Richard Smith Opened: 2018-03-24 Last modified: 2021-06-06

Priority: 2

View all issues with Resolved status.

Discussion:

What should happen here:

const int bpm = 100;
using beats = duration<int, ratio<60, 100>>;
auto v = time_of_day<beats>(beats{2}).subseconds();

? 2 beats at 100bpm is 1.2 seconds. The time_of_day constructor specification says:

seconds() returns the integral number of seconds since_midnight is after (00:00:00 + hours() + minutes()). subseconds() returns the integral number of fractional precision seconds since_midnight is after (00:00:00 + hours() + minutes() + seconds()).

But that's impossible. If seconds() returns 1, we need to return a subseconds() value representing 0.2s of type precision, but type precision can only represent multiples of 0.6s.

Should this time_of_day specialization only be available for the case where seconds is convertible to precision? Or should the precision type used by this specialization be common_type_t<seconds, duration<Rep, Period>> rather than merely duration<Rep, Period>?

Either way I think we need a wording update to specify one of those two behaviors.

[2018-04-09 Priority set to 2 after discussion on the reflector.]

[2019 Cologne Wednesday night]

Status to Resolved (group voted on NAD, but Marshall changed it to Resolved)

Resolved by the adoption of P1466 in Cologne.

hh_mm_ss is now specified such that subseconds must be a non-positive power of 10 (e.g. 1/10s, 1/100s, milliseconds, etc.). In this example 60/100 simplifies to 3/5, which can be exactly represented with 1 fractional decimal digit. So in this example subseconds() has the value of 2ds (2 deciseconds).

Proposed resolution: