Wrong clock_string<system_clock>::since() on Windows

[oliora@…]

clock_string<system_clock>::since() should return "since Jan 1, 1601" on Windows platform because FILETIME struct used in implementation is counted since specified date: ​http://msdn.microsoft.com/en-us/library/windows/desktop/ms724284.aspx.

[viboes]

Thanks for catching this. I will fix it as soon as possible.

[viboes]

Hi,

I believed that just changing the clock_string<system_clock>::since() for windows will be enough. However, if we want to be able to read a time_point output generated by a Windows machine from a Linux machine the parser needs to be aware of the differences.

An alternative is to use always "since Jan 1, 1900" and adapt the operators << and >> only on Windows machines. What do you think?

[oliora@…]

I think this is not an option because user will be confused why value of time_since_epoch() is different from printed value. Let's keep printed data the same as stored. I don't see the real problem in epoch difference between Window and Linux. Standard tells nothing about epoch concrete value or its exchangeability. And user always can convert time_point to time_t or user's own format to send data outside. But if you still want to make epoch the same on Windows and Linux, add conversion to now() function (to have time_since_epoch() the same on both platforms) but not to operator << and >>. Thank you

[viboes]

I have decided to don't fix as after the patch in #7868 version 2 for chrono/io works. Version 2 outputs a date instead of the time "since Jan 1, 1900" which solves the issue. Version 2 will be the default since version Boost 1.55.

[viboes]

Thinking a little bit more on that I don't see why clock_string<system_clock>::since() should return "since Jan 1, 1601" as e.g. std::time_t represents a date after midnight, January 1, 1970, UTC.

Anyway, I have reopened it as the output is not correct.

[oliora@…]

Because time_t is a number of seconds since January 1, 1970, UTC. But system_clock on Windows is a number of ticks since Jan 1, 1601.

[viboes]

Replying to oliora@…:

Because time_t is a number of seconds since January 1, 1970, UTC. But system_clock on Windows is a number of ticks since Jan 1, 1601.

I agree. I will fix the system clock so that count() give the periods "since January 1, 1970, UTC".

[oliora@…]

Are you going to fix number of ticks that time_point<system_clock> keeps internally? I.e. convert ('since' from system specific time) to ('since' January 1, 1970) on every platform? If so, it looks like good solution (for me at least).

[oliora@…]

Are you going to do this conversion only once, inside system_clock::now() ?

[viboes]

Replying to oliora@…:

Are you going to do this conversion only once, inside system_clock::now() ?

Yes.

[viboes]

There is an issue with gmtime on Windows when the time_t parameter is < 0. I have added an internal implementation for this function in Changeset [82562].

Then I have made that system clock counts periods "since January 1, 1970, UTC" And activated the use of the internal gmtime function on windows in Changeset [82563].

This should fix the issue for both Boost.Chrono versions, 1 or 2.

[viboes]

Changeset [82612] Chrono: merge [82562][82663].