Section: 30.7.2.1 [time.clock.system.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 335
Wording for clocks should be unified unless they are intended to behave differently
In 27.7.1.1 note 1 for system_clock
it is stated:
"Objects of type
system_clock
represent wall clock time from the system-wide realtime clock. Objects of typesys_time<Duration>
measure time since (and before) 1970-01-01 00:00:00 UTC"
The express statement of "since (and before)" is important given the time epoch of these clocks. If all the clocks support time prior to their zero-time then this should be stated explicitly. If not then likewise that should be noted. No change is proposed yet, clarification required over the intended behaviour when using values prior to a given clock's epoch is needed before the appropriate change can be suggested.
Proposed change: Unify the wording.Howard Hinnant:
The clocks that are specified to have a signedrep
imply that they will support
negative time points, but not how negative. For example if system_clock::duration
is nanoseconds
represented with 64 bits, then system_clock::time_point
can't possibly represent dates prior to 1677-09-21 00:12:43.145224192. This is a negative
time_point
since it is prior to 1970-01-01 00:00:00. But it is not very negative
compared to (for example) sys_time<microseconds>::min()
.
Those clocks with a signed rep
are:
system_clock
utc_clock
tai_clock
gps_clock
file_clock
Those clocks where the signed-ness of rep
is unspecified are:
steady_clock
high_resolution_clock
Therefore this response emphasizes the "Unify the wording" part of this NB comment.
[2019-11 Status to Ready during Wednesday morning issue processing in Belfast.]
Proposed resolution:
This wording is relative to N4835.
Modify 30.7.2.1 [time.clock.system.overview] as indicated:
-1- Objects of type
system_clock
represent wall clock time from the system-wide realtime clock. Objects of typesys_time<Duration>
measure time since(and before)1970-01-01 00:00:00 UTC excluding leap seconds. This measure is commonly referred to as Unix time. This measure facilitates an efficient mapping betweensys_time
and calendar types (30.8 [time.cal]). [Example:sys_seconds{sys_days{1970y/January/1}}.time_since_epoch()
is0s
.sys_seconds{sys_days{2000y/January/1}}.time_since_epoch()
is946'684'800s
, which is10'957 * 86'400s
. — end example]