On 08/22/2014 08:11 PM, Agustín K-ballo Bergé wrote:
On 22/08/2014 08:10 a.m., Bjorn Reese wrote:
How do we determine the epoch of trivial_clock?
Given a clock `C`, a default constructed `C::time_point` (or any instantiation of `time_point` for the clock `C`) represents the epoch of the clock. That is, for such a `time_point`, `time_since_epoch()` will return a duration of 0.
That is true by definition. My question was how do I determine the epoch of the clock in Gregorian time. My best attempt so far is to resort to <ctime>, because struct std::tm is relative to 1900-01-01. I can covert this into a std::time_t using std::mktime(), and then pass it to C::from_time_t(). However, there are two problems with this solution: 1. from_time_t() and to_time_t() are only required by system_clock, not by TrivialClock (as used by std/boost::filesystem.) 2. std::mktime() returns local time, but I need UTC. So I must invoke the thread-unsafe std::localtime() and std::gmtime() functions to compensate for timezones (and yes, I am aware of the _r counterparts but I am looking for a portable solution based on the C++ standard.)
It seems to me that what you need instead is to map a `time_point` from one clock to another, one that has an epoch under your control. That time_point could be the epoch of a clock. That is roughly done with:
tp2 = C2::now() + (tp1 - C1::now())
I can see two problems with this solution: 1. How do I create a clock with an epoch under my control? POSIX no longer gives guarantees about its epoch. 2. The two now() calls are not guaranteed to happen simultaneously, so it will introduce jitter. This jitter will become more salient as the clock resolution becomes more fine-grained. Notice that POSIX has APIs with nanosecond resolution on file timestamps: http://pubs.opengroup.org/onlinepubs/9699919799/functions/futimens.html