Design flaw in Date-Time Library?
Hi all, maybe this has already been discussed here!? 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. 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. Whats the rationale to make construction of this special case possible then? (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!? (But I would really favor a solution which regards a "ptime" equvalent to the special case of a "time_period" with zero duration). Regards, Frank ******************************************* Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorised copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. *******************************************
On Tue, 23 Mar 2004 12:16:02 +0100, Wolf, Frank wrote
Hi all,
maybe this has already been discussed here!?
Nope.
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...
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
participants (2)
-
Jeff Garland -
Wolf, Frank