You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To work around Boost's msec-precision UTC timer erroneously reporting local time instead of UTC on some systems, we're now also probing the sec-precision UTC timer, which should be more reliable in terms of time zone: The rounded difference between the two should be able to give us the time zone offset (if any) in the msec-precision timer, which we then compensate for accordingly.
To work around Boost's msec-precision UTC timer erroneously reporting local time instead of UTC on some systems, we're now also probing the sec-precision UTC timer, which should be more reliable in terms of time zone: The rounded difference between the two should be able to give us the time zone offset (if any) in the msec-precision timer, which we then compensate for accordingly.
Technically, this issue is fixed in v3.8.0, to be released in v3.8.0-beta.2.
However, the bug has highlighted the shortcomings of the current design, in that the typical use cases for the datetime function would be better catered to by a local time based solution. A mechanism should be devised to make local time output available as an intentional feature.
To work around Boost's msec-precision UTC timer erroneously reporting local time instead of UTC on some systems, we're now also probing the sec-precision UTC timer, which should be more reliable in terms of time zone: The rounded difference between the two should be able to give us the time zone offset (if any) in the msec-precision timer, which we then compensate for accordingly.
On Linux machines, the value returned by
now
may be based on local time, instead of UTC as documented and intended.This is due to an undocumented issue in
boost::posix_time::microsec_clock::universal_time()
.The text was updated successfully, but these errors were encountered: