Yea let's just duration_cast before calling to_time_t On Sat, Oct 8, 2016 at 4:23 PM Pavel Labath <lab...@google.com> wrote:
> labath added inline comments. > > > ================ > Comment at: include/lldb/Host/TimeValue.h:37-38 > explicit TimeValue(uint32_t seconds, uint64_t nanos = 0); > + TimeValue(std::chrono::time_point<std::chrono::system_clock, > + std::chrono::nanoseconds> > + point) > ---------------- > labath wrote: > > zturner wrote: > > > Is there any reason to explicitly prefer a nanosecond clock here as > opposed to `std::chrono::system_clock::duration`? For any system which > doesn't have nanosecond resolution, using a nanosecond clock is pointless, > and if some theoretical system had finer resolution, then using a > nanosecond clock would be limiting. So how about just > `std::chrono::time_point<std::chrono::system_clock>` and let the final > argument be deduced? > > If you let this argument be less precise you will get conversion errors > if someone tries to pass in a time point which has higher precision > (seconds are implicitly convertible to nanoseconds, but not the other way). > And struct timespec already (theoretically) has nanosecond precision, so we > would have to make an explicit choice to lose the precision at some level. > > > > `chrono::system_clock::time_point` has the precision at which the host > system clock hands out timestamps, but that doesn't mean it's impossible to > get higher precision timestamps, particularly if we start dealing with > remote systems. > I've hit one more annoying issue `system_clock::to_time_t` will not accept > a time point with precision greater than native system clock precision. > Sort of makes sense, although it's pretty pointless since time_t has only > second precision on all reasonable platforms. This means, if we use > nanosecond precision everywhere, we would have to cast, or roll our own > version of `to_time_t`. If we use native system clock precision, we lose > the ability to represent nanoseconds in some cases (and there are > filesystems storing timestamps with nanosecond precision), cannot represent > `struct timespec` nor the current `TimeValue`s correctly, and our time > functions would behave differently depending on the host os. I'd go with > the first option as it seems to have less drawbacks. > > I'll try to come up with a coherent proposal on the llvm side. Since it > seems we'll be putting these things there, I feel I should start by porting > the usage in llvm anyway. > > > https://reviews.llvm.org/D25392 > > > >
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
