Movatterモバイル変換

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

3316. Correctly define epoch forutc_clock /utc_timepoint

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

Priority:0

View all issues withC++20 status.

Discussion:

AddressesGB 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 theBIPM (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, whichwas the approximate accumulated difference between TAI and UT1 since the inception ofTAI in 1958, and a unique fraction of a second adjustment was applied so that UTC woulddiffer 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 andutc_timepoint should correctly report relative to the official UTC epoch. 27.2.2.1 footnote 1 should read:

In contrast tosys_time, which does not take leap seconds into account,utc_clock and its associatedtime_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() is0s.clock_cast<utc_clock>(sys_seconds{sys_days{2000y/January/1}}).time_since_epoch()is883'612'822, which is10'197 * 86'400s + 22s. —end example]

Howard Hinnant:

Clarify that the epoch ofutc_clock is intended to be1970-01-01.

Rationale: The main use case ofutc_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 thatutc_clock issystem_clock except thatutc_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 toN4835.

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

   -1- In contrast tosys_time, which does not take leap seconds into account,utc_clock and its associatedtime_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 constantsys_days{1972y/1/1} - sys_days{1970y/1/1} (63'072'000s) from theutc_time —end note] [Example:clock_cast<utc_clock>(sys_seconds{sys_days{1970y/January/1}}).time_since_epoch() is0s.clock_cast<utc_clock>(sys_seconds{sys_days{2000y/January/1}}).time_since_epoch()is946'684'822s, which is10'957 * 86'400s + 22s. —end example]