timegm is not cross platform. mktime is, but uses local time instead of
UTC.
> Is there a better way? Could not figure out how to use boost::chrono :(
> Something else?
Boost.Chrono is for time intervals, not dates.
Boost.DateTime, however, has the ptime class which will solve this for you.
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users
I think with C++11 something like:
std::chrono::duration_cast<std::chrono::milliseconds>(std::chrono::system_clock::now().time_since_epoch()).count()
might also do the trick.
Cheers,
Leon
Err, then again, it might not until C++20. C++11 embarrassingly failed
to state what the Epoch is. So for now clocks are free to use their own
and currently the above is useless for cross-platform applications (but
so is timegm). I wonder how this works on Windows with VS2019?
I wonder how this works on Windows with VS2019?
On Tue, 5 Mar 2019 at 01:51, Leon Mlakar via Boost-users <boost...@lists.boost.org> wrote:
I wonder how this works on Windows with VS2019?
It returns 1551766256847 (so the same as https://www.epochconverter.com/, i.e. "Unix Time"), there's no reason to assume it returns something else with VS2019 (AFAICS), until/unless it supports C++20 and the std explicitly changes the behavior (forces MS to break backward compatibility), you can be assured that it will be doing that for a while (until the Y38 problem raises its head).
Thank you for the information.
Behid the question was my, obviously incorrect, assumption that
older visual studio versions, from times when c++20 was not yet
conceived and epoch thus not set to Jan 1 AD 1970, are using some
different epoch - as Microsoft frequently did, like Jan 1 AD 1
(.NET), Jan 1 AD 1601 (NTFS), Jan 1 AD 1980 (DOS, FAT family of
file systems). So seeing Microsoft embracing a standard thing like
posix epoch without screaming and kicking is a nice surprise.
And it was late.
Cheers,
Leon
P.S. As for the Y38, std::chrono should be okay as it's not bound
to 32-bit integrals.
Behid the question was my, obviously incorrect, assumption that olde visual studio versions, from times when c++20 was not yet conceived and epoch thus not set to Jan 1 AD 1970, are using some different epoch - as Microsoft frequently did, like Jan 1 AD 1 (.NET), Jan 1 AD 1601 (NTFS),
Jan 1 AD 1980 (DOS, FAT family of file systems). So seeing Microsoft embracing a standard thing like posix epoch without screaming and kicking is a nice surprise.