[Boost-users] [date_time] local time & date arithmetics

Subject: [Boost-users] [date_time] local time & date arithmetics
From: Filip Konvička (filip.konvicka_at_[hidden])
Date: 2009-04-08 11:04:13

Hi all,

first, thanks for the date_time library. Although I see some issues with 
it, I still think it is highly needed and does a lot of good stuff for me.

Recently I stumbled upon a problem with date arithmetic that involves 
local_date_time. The following code fragment

   local_date_time t(
     ptime(boost::gregorian::date(2008, 4, 7), time_duration(22, 0, 0)),
     boost::shared_ptr<posix_time_zone>(new
       posix_time_zone("CET+1CEST,M4.1.0,M10.1.0")));
   cout << t.utc_time() << " UTC = " << t << endl;
   t -= boost::gregorian::days(6);
   cout << t.utc_time() << " UTC = " << t << endl;

yields the following output

2008-Apr-07 22:00:00 UTC = 2008-Apr-08 00:00:00 CEST
2008-Apr-01 22:00:00 UTC = 2008-Apr-01 23:00:00 CET

This indicates that the date operation just subtracted 6*24 hours from 
the internal representation of the local time. It missed the DST change 
within the time interval. I would rather expect the operation to do the 
following:

2008-Apr-07 22:00:00 UTC = 2008-Apr-08 00:00:00 CEST
2008-Apr-01 23:00:00 UTC = 2008-Apr-02 00:00:00 CET

If the current behavior is intentional, it is not clear to me why have 
such operations as "+= days(...)" available in local_date_time at all, 
as they don't seem to obey the general local time semantics (at least as 
I understand it) - we could just use an UTC ptime for that, right?

Another thing related to this is that many functions in local_date_time 
are inherited from the base class, which has a different semantics. From 
the user point of view, this seems to be quite dangerous - one has 
always to verify whether the function being called is overloaded in 
local_date_time (and so should have local time semantics) or whether it 
is defined in ptime and so works with the internal UTC representation. 
Why is the base class not protected?

Thanks for any comments,
Filip