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