On 04.03.2019 23:17, Gavin Lambert via Boost-users wrote:

On 4/03/2019 09:45, Victor Yankee wrote:

...

I am using C++14 and boost 1.64.0 (could move to newest boost), and need to convert date and time pieces to a single value for milliseconds since the epoch. This is what I have:

int64_t msSinceEpoch(int year,int month,int day,int hour,int minute,int second,int ms)              {              struct std::tm t;              t.tm_sec    = second;              t.tm_min    = minute;              t.tm_hour   = hour;              t.tm_mday   = day;              t.tm_mon    = month-1;              t.tm_year   = year-1900;              t.tm_isdst  = 0;              return (1000* timegm(&t))+ms; // is timegm cross-platform?              }

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.

I think with C++11 something like: std::chrono::duration_caststd::chrono::milliseconds(std::chrono::system_clock::now().time_since_epoch()).count() might also do the trick. Cheers, Leon

On Tue, 5 Mar 2019 at 01:51, Leon Mlakar via Boost-users < 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). degski -- *"Big boys don't cry" - **Eric Stewart, Graham Gouldman*

On Tue, 5 Mar 2019 at 10:39, Leon Mlakar via Boost-users < boost-users@lists.boost.org> wrote:

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),

MS just implements the standard [in this case] and for timings within Windows (i..e. Windows.h), they have the FILETIME API, " Jan 1 AD 1 (.NET), Jan 1 AD 1601 (NTFS)", etc (possibly because they realized the world was not created in 1970, but heck who knows).

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.

Well at the time of DOS, there was no std, so one could forgive them (on this occasion) to not implement it correctly. degski -- *"Big boys don't cry" - **Eric Stewart, Graham Gouldman*