[Boost-bugs] [Boost C++ Libraries] #3471: microseconds constructor overflows

Subject: [Boost-bugs] [Boost C++ Libraries] #3471: microseconds constructor overflows
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2009-09-21 16:19:26

#3471: microseconds constructor overflows
 Reporter: andysem | Owner: az_sw_dude
     Type: Bugs | Status: new
Milestone: Boost 1.41.0 | Component: date_time
  Version: Boost 1.40.0 | Severity: Problem
 Keywords: microseconds |
 From the users ML: [http://lists.boost.org/boost-users/2008/10/41763.php]

 The boost::date_time::microseconds(...) constructor overflows the int64
 limits in intermediary calculations. The code below will reproduce the
 (using VC++ 2008 and boost 1.36).

 ptime start(boost::gregorian::date(2000, 1, 1));
 ptime end(boost::gregorian::date(2000, 5, 1));
 time_duration td = end - start;

 ptime wrongEnd = start + microseconds(td.total_microseconds());
 BOOST_CHECK_EQUAL(end, wrongEnd);

 The microseconds constructor takes an int64 as input and the
 total_microseconds is well within its range. Inside the
 date_time::subsecond_duration<time_duration, 1000000> the internal
 is calculated as


 Since the both res_adjust() and frac_of_second have the value 1000000, the
 result should be ss*1 but... the intermediary value ss*res_adjust
 the int64 causing a negative number to be returned.

 Question is, is this by design or is it a bug? I'm rather new to
 boost::date_time and was hoping to replace our current datetime types with
 it. We are using millisecond timestamped data over long time series

 I guess the simple solution would be to add parentheses around
 (res_adjust()/frac_of_second) assuming frac_of_second always divides
 res_adjust. However, there are similar issues when adding 200 years worth
 seconds which overflows the int32 argument (but that's not of my immediate

Ticket URL: <https://svn.boost.org/trac/boost/ticket/3471>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:01 UTC