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

### 3316. Correctly define epoch for `utc_clock` / `utc_timepoint`

Section: 29.7.3.1 [time.clock.utc.overview] Status: C++20 Submitter: Great Britain Opened: 2019-11-05 Last modified: 2021-02-25

Priority: 0

View all issues with C++20 status.

Discussion:

Addresses GB 333

UTC epoch is not correctly defined UTC has an officially recorded epoch of 1/1/1972 00:00:00 and is 10 seconds behind TAI. This can be confirmed through reference to the BIPM (the body that oversees international metrology)

> "The defining epoch of 1 January 1972, `0 h 0m 0 s` UTC was set 10 s behind TAI, which was the approximate accumulated difference between TAI and UT1 since the inception of TAI in 1958, and a unique fraction of a second adjustment was applied so that UTC would differ from TAI by an integral number of seconds. The recommended maximum departure of UTC from UT1 was 0.7 s. The term "leap second" was introduced for the stepped second."

Proposed change:

`utc_clock` and `utc_timepoint` should correctly report relative to the official UTC epoch. 27.2.2.1 footnote 1 should read:

> In contrast to `sys_time`, which does not take leap seconds into account, `utc_clock` and its associated `time_point`, `utc_time`, count time, including leap seconds, since 1972-01-01 00:00:00 UTC. [Example: `clock_cast<utc_clock>(sys_seconds{sys_days{1972y/January/1}}).time_since_epoch()` is `0s`. `clock_cast<utc_clock>(sys_seconds{sys_days{2000y/January/1}}).time_since_epoch()` is `883'612'822`, which is `10'197 * 86'400s + 22s`. — end example]

Howard Hinnant:

Clarify that the epoch of `utc_clock` is intended to be `1970-01-01`.

Rationale: The main use case of `utc_clock` is to get the correct number of seconds when subtracting time points straddling a leap second insertion point, and this computation is independent of the epoch. Furthermore learning/teaching that `utc_clock` is `system_clock` except that `utc_clock` includes leap seconds is easier. And this fact is more easily understood when comparing the underlying `.time_since_epoch()` of equivalent time points from each clock.

[2019-11 Status to Ready during Wednesday morning issue processing in Belfast.]

Proposed resolution:

This wording is relative to N4835.

1. Modify 29.7.3.1 [time.clock.utc.overview] as indicated:

   > -1- In contrast to `sys_time`, which does not take leap seconds into account, `utc_clock` and its associated `time_point`, `utc_time`, count time, including leap seconds, since 1970-01-01 00:00:00 UTC. [Note: The UTC time standard began on 1972-01-01 00:00:10 TAI. To measure time since this epoch instead, one can add/subtract the constant `sys_days{1972y/1/1} - sys_days{1970y/1/1}` (`63'072'000s`) from the `utc_time` — end note] [Example: `clock_cast<utc_clock>(sys_seconds{sys_days{1970y/January/1}}).time_since_epoch()` is `0s`. `clock_cast<utc_clock>(sys_seconds{sys_days{2000y/January/1}}).time_since_epoch()` is `946'684'822s`, which is `10'957 * 86'400s + 22s`. — end example]