954. Various threading bugs #4

Section: 30.3 [time.clock.req] Status: C++11 Submitter: Pete Becker Opened: 2009-01-07 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [time.clock.req].

View all issues with C++11 status.

Discussion:

Table 55 — Clock Requirements (in 30.3 [time.clock.req])

  1. the requirements for C1::time_point require C1 and C2 to "refer to the same epoch", but "epoch" is not defined.
  2. "Different clocks may share a time_point definition if it is valid to compare their time_points by comparing their respective durations." What does "valid" mean here? And, since C1::rep is "THE representation type of the native duration and time_point" (emphasis added), there doesn't seem to be much room for some other representation.
  3. C1::is_monotonic has type "const bool". The "const" should be removed.
  4. C1::period has type ratio. ratio isn't a type, it's a template. What is the required type?

[ 2009-05-10 Howard adds: ]

  1. "epoch" is purposefully not defined beyond the common English definition. The C standard also chose not to define epoch, though POSIX did. I believe it is a strength of the C standard that epoch is not defined. When it is known that two time_points refer to the same epoch, then a definition of the epoch is not needed to compare the two time_points, or subtract them.

    A time_point and a Clock implicitly refer to an (unspecified) epoch. The time_point represents an offset (duration) from an epoch.

  2. The sentence:

    Different clocks may share a time_point definition if it is valid to compare their time_points by comparing their respective durations.

    is redundant and could be removed. I believe the sentence which follows the above:

    C1 and C2 shall refer to the same epoch.

    is sufficient. If two clocks share the same epoch, then by definition, comparing their time_points is valid.

  3. is_monotonic is meant to never change (be const). It is also desired that this value be usable in compile-time computation and branching.
  4. This should probably instead be worded:

    An instantiation of ratio.

[ Batavia (2009-05): ]

Re (a): It is not clear to us whether "epoch" is a term of art.

Re (b), (c), and (d): We agree with Howard's comments, and would consider adding to (c) a static constexpr requirement.

Move to Open pending proposed wording.

[ 2009-05-25 Daniel adds: ]

In regards to (d) I suggest to say "a specialization of ratio" instead of "An instantiation of ratio". This seems to be the better matching standard core language term for this kind of entity.

[ 2009-05-25 Ganesh adds: ]

Regarding (a), I found this paper on the ISO website using the term "epoch" consistently with the current wording:

http://standards.iso.org/ittf/PubliclyAvailableStandards/C030811e_FILES/MAIN_C030811e/text/ISOIEC_18026E_TEMPORAL_CS.HTM

which is part of ISO/IEC 18026 "Information technology -- Spatial Reference Model (SRM)".

[ 2009-08-01 Howard: Moved to Reivew as the wording requested in Batavia has been provided. ]

[ 2009-10 Santa Cruz: ]

Move to Ready.

Proposed resolution:

  1. Change 30.3 [time.clock.req] p1:

    -1- A clock is a bundle consisting of a native duration, a native time_point, and a function now() to get the current time_point. The origin of the clock's time_point is referred to as the clock's epoch as defined in section 6.3 of ISO/IEC 18026. A clock shall meet the requirements in Table 45.

  2. Remove the sentence from the time_point row of the table "Clock Requirements":

    Clock requirements
    C1::time_point chrono::time_point<C1> or chrono::time_point<C2, C1::duration> The native time_point type of the clock. Different clocks may share a time_point definition if it is valid to compare their time_points by comparing their respective durations. C1 and C2 shall refer to the same epoch.
  3. Change the row starting with C1::period of the table "Clock Requirements":

    Clock requirements
    C1::period a specialization of ratio The tick period of the clock in seconds.