@laanwj Best I can tell from google and reading the c spec, it's not guaranteed to be based on the UNIX epoch either :(. Of course, I've never seen an implementation that isn't, as that would likely break years worth of assumptions. And based on that, I would assume that c++ implementations will be using the underlying c implementation.
So my logic was: if we can run a quick sanity check here to be sure that c/c++/unix epoch are all aligned, then we can use c apis and std::chrono interchangeably throughout the codebase without worry.
As for why chrono here, it was to avoid gettimeofday portability issues. If you'd prefer to work around those instead, no problem.
You're right though that DateTimeStrFormat is kinda clunky. I only used c++ there to avoid c string size guessing. I'm also happy to switch that if you'd prefer.
Best I can tell from google and reading the c spec, it's not guaranteed to be based on the UNIX epoch either :(
Which ones? The man page of "gmtime" tells me the following:
The ctime(), gmtime() and localtime() functions all take an argument of data type time_t, which represents calendar time. When interpreted as an absolute time value, it represents the
number of seconds elapsed since the Epoch, 1970-01-01 00:00:00 +0000 (UTC).
Same for gettimeofday:
and gives the number of seconds and microseconds since the Epoch (see time(2)). The tz argument is a struct timezone:
If using std::chrono makes anything less hassle I'm fine with using it. It just seems like a lot of code necessary to work around issues (and that's just to get started using it!), but you're right that gettimeofday and strftime have their own issues.
@laanwj Posix uses a value since the Unix epoch, but time_t is implementation-defined according to the c spec. But it really doesn't matter, realistically it'll be the Unix epoch everywhere we run. Sorry for the distraction.
I only brought it up because the c++ system_clock's epoch is technically implementation-defined as well, I was just making the case that it's probably just as safe to assume as with c.
+{
+ // std::chrono::system_clock.time_since_epoch and time_t(0) are not guaranteed
+ // to use the Unix epoch timestamp, but in practice they almost certainly will.
+ // Any differing behavior will be assumed to be an error, unless certain
+ // platforms prove to consistently deviate, at which point we'll cope with it
+ // by adding offsets.
+
+ // Create a new clock from time_t(0) and make sure that it represents 0
+ // seconds from the system_clock's time_since_epoch. Then convert that back
+ // to a time_t and verify that it's the same as before.
Needing something like this makes me wonder if we're not better off just using the C time functions, which guarantee being based on the UNIX epoch.
Especially as we're already probing for gmtime_int anyway. This seems double.
Do we need something that is only offered by std::chrono? (or needs much less code with std::chrono)