Proposed resolution:

This wording is relative to the FDIS.

1. In [time.point.nonmember], p.1 change the Returns element semantics as indicated:

   template <class Clock, class Duration1, class Rep2, class Period2>
   time_point<Clock, typename common_type<Duration1, duration<Rep2, Period2>>::type>
   operator+(const time_point<Clock, Duration1>& lhs, const duration<Rep2, Period2>& rhs);
   

   -1- Returns: CT(lhs) += rhsCT(lhs.time_since_epoch() + rhs), where CT is the type of the return value.

[ 2012, Portland ]

Resolved by adopting paper n3469.

It has been observed by LWG 2054 that the specification of some time_point member functions already imply that time_point needs to be a literal type and suggests to specify the constructors and the member function time_since_epoch() as constexpr functions at the minimum necessary. Adding further constexpr specifier to other operations should clearly be allowed and should probably be done as well. But to allow for further constexpr functions in the future requires that their semantics is compatible to operations allowed in constexpr functions. This is already fine for all operations, except this binary plus operator:

template <class Clock, class Duration1, class Rep2, class Period2>
time_point<Clock, typename common_type<Duration1, duration<Rep2, Period2>>::type>
operator+(const time_point<Clock, Duration1>& lhs, const duration<Rep2, Period2>& rhs);

-1- Returns: CT(lhs) += rhs, where CT is the type of the return value.

for similar reasons as those mentioned in 2020. The semantics should be fixed to allow for making them constexpr. This issue should also be considered as a placeholder for a request to make the remaining time_point operations similarly constexpr as had been done for duration.