Title
subsecond-precision time_of_day and durations that seconds cannot convert to
Status
resolved
Section
[time.hms]
Submitter
Richard Smith

Created on 2018-03-24.00:00:00 last changed 64 months ago

Messages

Date: 2019-07-23.15:20:52

[ 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).

Date: 2018-04-09.00:00:00

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

Date: 2018-03-24.00:00:00

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.

History
Date User Action Args
2019-07-23 15:20:52adminsetmessages: + msg10494
2019-07-23 15:20:52adminsetstatus: new -> resolved
2018-04-22 14:05:42adminsetmessages: + msg9817
2018-03-24 00:00:00admincreate