[Boost-users] Bug or feature? date_time::microseconds limitations?

Subject: [Boost-users] Bug or feature? date_time::microseconds limitations?
From: athor (thorena_at_[hidden])
Date: 2008-10-30 04:26:09

The boost::date_time::microseconds(...) constructor overflows the int64 size
limits in intermediary calculations. The code below will reproduce the error
(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 duration
is calculated as

ss*traits_type::res_adjust()/frac_of_second

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 overflows
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 (years).

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 of
seconds which overflows the  int32 argument (but that's not of my immediate
concern).

-- 
View this message in context: http://www.nabble.com/Bug-or-feature--date_time%3A%3Amicroseconds-limitations--tp20210968p20210968.html
Sent from the Boost - Users mailing list archive at Nabble.com.