Proposed resolution:

This wording is relative to SG3 working draft.

1. Change the last write time prototype specification, 15.25 [fs.op.last_write_time], as indicated:

   file_time_type last_write_time(const path& p);
   file_time_type last_write_time(const path& p, error_code& ec) noexcept;
   

   Returns: The time of last data modification of p, determined as if by the value of the POSIX stat structure member st_mtime obtained as if by POSIX stat(). The signature with argument ec returns static_cast<file_time_type>(-1)file_time_type::min() if an error occurs.

[ 2014-02-13 LWG/SG-3 Issaquah: Proposed wording accepted. ]

[ 2014-02-08 Daniel comments and provides wording ]

I agree that the current wording needs to be fixed, but it is unclear to me whether invoking from_time_t (which is only guaranteed to exist for std::chrono::system_clock) with a value of time_t(-1) is a well-defined operation. Reason is that the C Standard makes a difference between a calendar time and the value time_t(-1) as an error indication. But the specification of system_clock::from_time_t only says "A time_point object that represents the same point in time as t […]" and it is not clear whether time_t(-1) can be considered as a "point in time". Instead of relying on such a potentially subtle semantics of the conversion result of time_t(-1) to std::chrono::system_clock::time_point with a further conversion to file_time_type (which in theory could led to overflow or underflow and thus another potential source of undefined behaviour), I suggest to change the current error value of last_write_time to one of the well-define limiting values of file_time_type, e.g. file_time_type::min().

Addresses: filesys.ts

In last_write_time, static_cast<file_time_type>(-1) is ill formed, (possibly should be chrono<unspecified-trivial-clock>::from_time_t(-1)).