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

**Section:** 29.9 [time.hms] **Status:** Resolved
**Submitter:** Richard Smith **Opened:** 2018-03-24 **Last modified:** 2021-06-06 18:38:24 UTC

**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:**