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.
Section: 29.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: