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]