Opened 10 years ago
Closed 10 years ago
#7525 closed Bugs (fixed)
Wrong clock_string<system_clock>::since() on Windows
Reported by: | Owned by: | viboes | |
---|---|---|---|
Milestone: | Boost 1.53.0 | Component: | chrono |
Version: | Boost 1.51.0 | Severity: | Cosmetic |
Keywords: | chrono system_clock windows | Cc: |
Description
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.
Change History (12)
comment:1 by , 10 years ago
Status: | new → assigned |
---|
comment:2 by , 10 years ago
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?
comment:3 by , 10 years ago
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
comment:4 by , 10 years ago
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
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.
comment:5 by , 10 years ago
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
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.
follow-up: 7 comment:6 by , 10 years ago
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.
comment:7 by , 10 years ago
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".
comment:8 by , 10 years ago
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).
follow-up: 10 comment:9 by , 10 years ago
Are you going to do this conversion only once, inside system_clock::now() ?
comment:10 by , 10 years ago
Replying to oliora@…:
Are you going to do this conversion only once, inside system_clock::now() ?
Yes.
comment:11 by , 10 years ago
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.
comment:12 by , 10 years ago
Milestone: | To Be Determined → Boost 1.53.0 |
---|---|
Resolution: | → fixed |
Status: | reopened → closed |
Thanks for catching this. I will fix it as soon as possible.