Boost C++ Libraries: Ticket #7525: Wrong clock_string::since() on Windows

status changed

viboes — Sun, 21 Oct 2012 09:18:23 GMT

status new → assigned

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

viboes — Mon, 22 Oct 2012 17:22:34 GMT

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@… — Mon, 22 Oct 2012 21:19:01 GMT

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

status changed; resolution set

viboes — Fri, 18 Jan 2013 21:27:49 GMT

status assigned → closed
resolution → wontfix

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.

status changed; resolution deleted

viboes — Sat, 19 Jan 2013 22:06:46 GMT

status closed → reopened
resolution wontfix

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@… — Sun, 20 Jan 2013 12:01:08 GMT

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 — Sun, 20 Jan 2013 12:56:29 GMT

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@… — Sun, 20 Jan 2013 13:41:18 GMT

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@… — Sun, 20 Jan 2013 13:42:14 GMT

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

viboes — Sun, 20 Jan 2013 16:19:28 GMT

Replying to oliora@…:

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

Yes.

viboes — Sun, 20 Jan 2013 16:19:50 GMT

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.

status, milestone changed; resolution set

viboes — Sun, 27 Jan 2013 12:35:24 GMT

status reopened → closed
resolution → fixed
milestone To Be Determined → Boost 1.53.0

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