Proposed resolution:

1. Change [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.

[ 2009-10 Santa Cruz: ]

Move to Ready.

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

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

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

Table 55 — Clock Requirements (in [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?