I'm using Boost's datetime library in my project. I was very happy when I discovered that it has time duration types for hours, days, months, years, etc, and they change their value based on what you're adding them to (i.e. adding 1 month advances the month part of the date, it doesn't just add 30 days or somesuch). I thought this property held for the days type, but I decided to test it before I put it into production...
local_date_time t1(date(2010, 3, 14), hours(1), easternTime, false); // 1am on DST transition date
{
CPPUNIT_ASSERT_EQUAL(greg_year(2010), t1.local_time().date().year());
CPPUNIT_ASSERT_EQUAL(greg_month(3), t1.local_time().date().month());
CPPUNIT_ASSERT_EQUAL(greg_day(14), t1.local_time().date().day());
CPPUNIT_ASSERT_EQUAL(1L, t1.local_time().time_of_day().hours());
CPPUNIT_ASSERT_EQUAL(0L, t1.local_time().time_of_day().minutes());
CPPUNIT_ASSERT_EQUAL(0L, t1.local_time().time_of_day().seconds());
}
t1 += days(1); // the time in EST should now be 1am on the 15th
{
CPPUNIT_ASSERT_EQUAL(greg_year(2010), t1.local_time().date().year());
CPPUNIT_ASSERT_EQUAL(greg_month(3), t1.local_time().date().month());
CPPUNIT_ASSERT_EQUAL(greg_day(15), t1.local_time().date().day());
CPPUNIT_ASSERT_EQUAL(1L, t1.local_time().time_of_day().hours()); // fails, returns 2
CPPUNIT_ASSERT_EQUAL(0L, t1.local_time().time_of_day().minutes());
CPPUNIT_ASSERT_EQUAL(0L, t1.local_time().time_of_day().seconds());
}
Above you'll see my CPPUNIT unit test. It fails at the indicated line with 2, which is what I would expect if days() merely added 24 hours, instead of 1 logical day (since the DST transition causes 2010-03-14 to be 23 hours long in EST).
Am I doing something wrong? Is this a bug? Did I just completely misunderstand the design goal of the library with respect to this sort of math?