Hi, I am looking at the possibility of replacing our custom-made datetime classes with the ones from boost::date_time. The library looks very attractive to me, and I would certainly go ahead and use it... however there is (at least) one catch, and this is the snap-to-end-of-month behavior of the months duration, according to which: {2000-Feb-29} + {1 month} = {2000-Mar-31} The problem is that it contradicts to the XSD spec we are using, http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#adding-durations-to-date..., that says that months must be just "pinned to be within range". Maybe there is (could be added) some sort of policy, that could be used to achieve this behavior? Thanks, Arkadiy
Arkadiy Vertleyb wrote:
Hi,
I am looking at the possibility of replacing our custom-made datetime classes with the ones from boost::date_time. The library looks very attractive to me, and I would certainly go ahead and use it... however there is (at least) one catch, and this is the snap-to-end-of-month behavior of the months duration, according to which:
{2000-Feb-29} + {1 month} = {2000-Mar-31}
The problem is that it contradicts to the XSD spec we are using, http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#adding-durations-to-date..., that says that months must be just "pinned to be within range". Maybe there is (could be added) some sort of policy, that could be used to achieve this behavior?
I've tried to read this algorithm before and I have to say I've never fully understood it. As for policies, the implementation is already policy based. You could write a new month_functor class to replace the one that the library uses. The signature is template<class date_type> class month_functor { public: duration_type get_offset(const date_type& d) const {} duration_type get_neg_offset(const date_type& d) const {} Where get_neg_offset handles subtraction and get_offset is for addition. You can see date_time/adjust_functors.hpp for the current implementation. After you write your new function you'll need to create your own duration types or replace the ones in date_time/gregorian/greg_duration_types.hpp so that you can do cool stuff like: date d(2000,3,31); d += months(3); Jeff
"Jeff Garland"
Arkadiy Vertleyb wrote:
Hi,
I am looking at the possibility of replacing our custom-made datetime classes with the ones from boost::date_time. The library looks very attractive to me, and I would certainly go ahead and use it... however there is (at least) one catch, and this is the snap-to-end-of-month behavior of the months duration, according to which:
{2000-Feb-29} + {1 month} = {2000-Mar-31}
The problem is that it contradicts to the XSD spec we are using, http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#adding-durations-to-date..., that says that months must be just "pinned to be within range". Maybe there is (could be added) some sort of policy, that could be used to achieve this behavior?
I've tried to read this algorithm before and I have to say I've never fully understood it. As for policies, the implementation is already policy based. You could write a new month_functor class to replace the one that the library uses. The signature is
template<class date_type> class month_functor { public: duration_type get_offset(const date_type& d) const {} duration_type get_neg_offset(const date_type& d) const {}
Where get_neg_offset handles subtraction and get_offset is for addition. You can see date_time/adjust_functors.hpp for the current implementation. After you write your new function you'll need to create your own duration types or replace the ones in date_time/gregorian/greg_duration_types.hpp so that you can do cool stuff like:
date d(2000,3,31); d += months(3);
OK, thanks, I'll look at this. Regards, Arkadiy
participants (2)
-
Arkadiy Vertleyb -
Jeff Garland