GB333 27.02.2.1 Correctly define epoch for utc_clock / utc_timepoint LWG 3316

[wg21bot]

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)
​https://www.bipm.org/cc/CCTF/Allowed/18/CCTF_09-32_noteUTC.pdf
Specifically page 6
"The defining epoch of 1 January 1972, 0 h 0 m 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]

[HowardHinnant]

The current spec describes as "utc_clock as system_clock but counts leap seconds."

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.

Here is a program which clients can easily write to demonstrate:

    #include <chrono>
    #include <iostream>

    int
    main()
    {
        using namespace std;
        using namespace std::chrono;
        auto now_sys = floor<seconds>(system_clock::now());
        auto now_utc = clock_cast<utc_clock>(now_sys);
        cout << now_utc.time_since_epoch() - now_sys.time_since_epoch() << '\n';
    }

Output:

    27s

The output proposed by this comment would be:

    -63071973s

The proposed change is doable, but has a benefit/cost ratio that is less than 1 by making the library harder to understand and use. The true fact that is used as the motivation for this example is outweighed by the fact that the major benefit of utc_time is exact subtraction of time_points across leap second insertions.

auto t0_sys = sys_days{2016y/December/31} + 23h + 59min + 59s;
auto t1_sys = sys_days{2017y/January/1} + 0s;
auto t0_utc = clock_cast<utc_clock>(t0_sys);
auto t1_utc = clock_cast<utc_clock>(t1_sys);
cout << "delta sys = " << t1_sys - t0_sys << '\n';
cout << "delta utc = " << t1_utc - t0_utc << '\n';

Output:

delta sys = 1s
delta utc = 2s

This major benefit doesn't depend on the epoch. And explaining/teaching/demonstrating what utc_clock represents under the hood is simple if we can say: utc_clock is system_clock except that it counts leap seconds.

Proposed wording:

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

[jwakely]

Reviewed by LWG small group on Monday morning and Monday Afternoon.

[Dani-Hub]

The associated issue is LWG 3316

[mclow]

LWG 3316 is Ready.