RE: [boost] Re: reminder about Date/Time formal review

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-04-24 08:17:32

> 1.  iostream based reading and writing of date and ptime, -INCLUDING- some
> form of explicit formatting.  Parsing date and time strings is currently
> very difficult, and I would love to eventually use boost::lexical_cast to
> get from "23:56" or "2002-03-02" to a date or ptime.

Agreed.
 
> 2.  A better example, or built in support for business day calculations.
> Once Easter and the other "hard" holidays are in there, I will be adding
> "size_t business_days_between(ptime start, ptime end);" to my personal
> library, if it's not in GDTL.  It wasn't clear to me how to intersect a
> complex set of distinct days (the holidays, and all of the weekends) with a
> simple date_period.

We can do that.  Did you look at the period calc example?  It does something
very similar to this.  It uses an std::set of date_periods to represent
exclusion periods -- the weekends and holidays.  A holiday becomes a 1 day 
exclusion period.  Then it checks to see if a given date is within the set 
of excluded periods.  If you change the last bit to a date_period instead
of a date I think you will have it.

http://www.crystalclearsoftware.com/libraries/gdtl/user_docs/period__calc_8cpp-example.html

> Other comments:
> 
> I'm hopeful that the final version will work "out of the box" for VS6SP5 by
> avoiding the int64 types automatically based on <boost/config.hpp> settings.

This seems to be an issue with the standard library that is used.  That is,
if you use the upgraded Dinkumware library it is ok.  Unfortunately, this
is just my guess based on trying to figure out why it works for some and 
not for others.  I'm not sure if there is a good way to detect this.  As
far as I know there isn't a config macro for this.  So we really have 2
options.  1) We can back off nano-second time resolution on VC6SP5 by 
default, or 2) we can provide patches to be applied with instructions
when users encounter failures.  My guess is that 2 would be preferred.

 
> Overall, there's a lot to like here, so thanks to Jeff for a great effort in
> getting GDTL to where it is today.

Thanks.

Jeff