Title
Clarify whether clocks can represent time before their epoch
Status
c++20
Section
[time.clock.system.overview]
Submitter
Great Britain

Created on 2019-11-05.00:00:00 last changed 38 months ago

Messages

Date: 2019-11-07.08:09:03

Proposed resolution:

This wording is relative to N4835.

  1. Modify [time.clock.system.overview] as indicated:

    -1- Objects of type system_clock represent wall clock time from the system-wide realtime clock. Objects of type sys_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 between sys_time and calendar types ([time.cal]). [Example: sys_seconds{sys_days{1970y/January/1}}.time_since_epoch() is 0s. sys_seconds{sys_days{2000y/January/1}}.time_since_epoch() is 946'684'800s, which is 10'957 * 86'400s. — end example]

Date: 2019-11-07.08:09:03

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

Date: 2019-11-05.00:00:00

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 type sys_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 signed rep 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.

History
Date User Action Args
2021-02-25 10:48:01adminsetstatus: wp -> c++20
2020-02-24 16:02:59adminsetstatus: voting -> wp
2020-01-17 04:54:50adminsetstatus: ready -> voting
2019-11-07 08:09:03adminsetmessages: + msg10781
2019-11-07 08:09:03adminsetstatus: new -> ready
2019-11-05 20:12:06adminsetmessages: + msg10752
2019-11-05 00:00:00admincreate