On Sun, May 18, 2008 at 04:17:41PM +0300, Igor R. wrote:
Why is subtraction of periods less "specific to the date_time library", than the following functions? contains(), intersects(), intersection(), shift(), expand(), merge(), span()
Ugh, it's not; I wasn't aware that they were already included in the library. They are all good candidates for generalization and placement in a separate library/class. IMHO.
Subtraction of intervals seems to be very "native" operation for time_period, since it's VERY common task when working with time intervals.
I'm the wrong person to complain to. The class seems generally unable to represent non-convex sets, e.g. the documentation for the "merge" method says: "Returns union of two periods. Null if no intersection." So the union of disjoint intervals [2,3] and [4,5] will return null. (Yes, it's still possible to write a difference operator crippled[*] in the same way as the merge operator. Hence the suggestion for factoring into a separate general-purpose library.) [*] Conditionally speaking crippled. Period is explicitly defined as "[.. range] between two times", something that the set [2,3] U [4,5] most definitely is not. I.e. I'd say you're using the wrong tool for the job.