On 05.03.2019 07:11, degski via Boost-users wrote:
On Tue, 5 Mar 2019 at 01:51, Leon Mlakar via Boost-users
mailto:boost-users@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.