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(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