Re: [boost] Design flaw in Date-Time Library?

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-03-23 09:09:40

On Tue, 23 Mar 2004 12:16:02 +0100, Wolf, Frank wrote
> Hi all,
> 
> maybe this has already been discussed here!?

Nope.

> I have a problem constructing an "time_period" object with a 
> duration of zero which seems to be a special case not handled 
> properly in my opinion.

Ok.

> According the comments in one of the headers constructing a "time_period"
> with zero duration is not possible; i.e. the duration is at least 1.

Where is this?

> Whats the rationale to make construction of this special case 
> possible then?

I suspect that the comment is incorrect.  The period does have support for the
concept of a 'null' time period.  Construction with a zero duration is one way
to create a null period.  But there is more to this...see below...

> (see code sample). That means what's the rationale not to handle the 
> special case of a zero duration?
> 
> Please see the following sample code:
> ------------------------------------------------------------------------
> {
>   // Contruct a time_period representing a whole day
>   ptime pToday(date(2004, 2, 29) );
>   time_period wholeDay(pToday, time_duration(24, 0, 0) );
>   std::cout << to_simple_string(wholeDay) << std::endl;
> 
>   // Contruct a time_period representing just the next point of time
>   ptime pTomorrow(date(2004, 3, 1) );
>   time_period wholeDay2(pTomorrow, time_duration(0, 0, 0) );
>   std::cout << to_simple_string(wholeDay2) << std::endl;
> 
>   // Our second period is not contained in the first one
>   if (wholeDay.contains(wholeDay2) != false)
>     std::cout << "Error" << std::endl;
> }
> ------------------------------------------------------------------------
> 
> gives:
> 
> [2004-Feb-29 00:00:00/2004-Feb-29 23:59:59.999999] // Correct
> [2004-Mar-01 00:00:00/2004-Feb-29 23:59:59.999999] // Wrong?
> Error?                                             // Wrong!!!
> 
> >From my understanding the second time_period is not contained in the
> first one, but the design of the library gives such a result.
> 
> Wouldn't it make sense to change the definition of the "time_period" 
> class to handle the special case of a zero duration too? At least it 
> should not be possible to construct a "time_period" with zero duration!?

I agree that the behavior of 'contains' versus a 'null' period is not correct.
 The problem is, what is correct?  I can see the argument that the null period
is really defined as a degenerate 'point in time' as you describe below. 
Unfortunately, that isn't how the library defines it.  Another way to
currently define a null period is

ptime pToday(date(2004, 3, 23));
ptime before(date(2001,1,1)); 
time_period tp(pToday, before); //tp.is_null() == true

So, the thing that strikes me is that these probably need to be different
cases.  That is, the example above is probably 'invalid' and should either
throw and exception on construction or create an invalid state for the
time period.  Even worse, it appears that the library already has some
checking for the null case which violates the degenerate idea:

ptime first(date(2004, Jan, 1) );
ptime second(date(2004, Feb, 1) );
ptime third(date(2004, Mar, 1) );
time_period zero_length(second, time_duration(0, 0, 0) );

//current results...
zero_length.is_before(first) == false
zero_length.is_after(first) == false
zero_length.is_before(third) == false
zero_length.is_after(third) == false

Certainly not what you are thinking and doesn't seem correct.

> (But I would really favor a solution which regards a "ptime" 
> equvalent to the special case of a "time_period" with zero duration).

I believe I agree, but it is going to take awhile to evaluate the impact.  In
the meantime, I recommend using is_null() to avoid this.  Or if you want to
take a crack at changing the logic on your own it is really a matter of
modifying the date_time/period.hpp file.

Jeff