[Pharo-project] Timespan #intersection: yields wrong result
Hi, I traced a bug when working with timespans to the following issue illustrated in the code snippet below. The last expression in the snippet yields false, although it should yield true (imho). |start end span| start :=DateAndTime now. end := start + 1 hour. span := Timespan starting: start ending: end. (span intersection: span) = span --> false I think that the intersection of a span with itself, should be itself. The origin of the problem is that Timespan>>intersection: creates a new timespan roughly as follows: Timespan starting: aBegin ending: self end. But Timespan>>end returns the end time of the timespan minus the clockprecision. As such, the intersecting span is a nanosecond shorter than the one we would expect. This eventually yields wrong results when working with timespans. The real question now is: should the implementation of Timespan>>intersection be changed -or- should Timespan>>end really return the (non-included) end time (that was passed when constructing it)? I sent this email to bugs@chronos-st.org, but a discussion here probably will not hurt either. Best regards Johan Brichau
On Tuesday 03 May 2011 19:25:47 Johan Brichau wrote:
Hi,
I traced a bug when working with timespans to the following issue illustrated in the code snippet below. The last expression in the snippet yields false, although it should yield true (imho).
|start end span| start :=DateAndTime now. end := start + 1 hour. span := Timespan starting: start ending: end. (span intersection: span) = span --> false
I think that the intersection of a span with itself, should be itself. The origin of the problem is that Timespan>>intersection: creates a new timespan roughly as follows:
Timespan starting: aBegin ending: self end.
But Timespan>>end returns the end time of the timespan minus the clockprecision. As such, the intersecting span is a nanosecond shorter than the one we would expect. This eventually yields wrong results when working with timespans.
The real question now is: should the implementation of Timespan>>intersection be changed -or- should Timespan>>end really return the (non-included) end time (that was passed when constructing it)? Hi,
I wrote this Chronology stuff, so I can assure you that the behaviour is deliberate. You never want overlapping timespans. ever :) Let me know if you want some more details. Brent
On 03 May 2011, at 20:44, Brent Pinkney wrote:
I wrote this Chronology stuff, so I can assure you that the behaviour is deliberate. You never want overlapping timespans. ever :)
Let me know if you want some more details.
Yes, please, because it's not making sense to me. I understand "overlapping timespans" as timespans that have a non-empty intersection, so I cannot follow that remark. The intersection of 2 timespans is implemented to be smaller (exactly one clockPrecision unit) than it really is? In the end, because I'm working with timespans in a scheduling application, I get funny gaps of a nanosecond between the timespans. Mind that I understand that timespans are left-closed right-open intervals. The point is that the "right end" is a nanosecond off after taking the intersection, imho. What is even funnier is that if you loop the script I sent, you eventually end up with an empty intersection... because it gets smaller all the time. So yes, I cannot understand that :-( Johan
BTW johan did you also check aconcagua? Stef On May 3, 2011, at 7:25 PM, Johan Brichau wrote:
Hi,
I traced a bug when working with timespans to the following issue illustrated in the code snippet below. The last expression in the snippet yields false, although it should yield true (imho).
|start end span| start :=DateAndTime now. end := start + 1 hour. span := Timespan starting: start ending: end. (span intersection: span) = span --> false
I think that the intersection of a span with itself, should be itself. The origin of the problem is that Timespan>>intersection: creates a new timespan roughly as follows:
Timespan starting: aBegin ending: self end.
But Timespan>>end returns the end time of the timespan minus the clockprecision. As such, the intersecting span is a nanosecond shorter than the one we would expect. This eventually yields wrong results when working with timespans.
The real question now is: should the implementation of Timespan>>intersection be changed -or- should Timespan>>end really return the (non-included) end time (that was passed when constructing it)?
I sent this email to bugs@chronos-st.org, but a discussion here probably will not hurt either.
Best regards Johan Brichau
Stef, No, and it seems I have mixed up Chronology and Chronos. I just got an answer from Alan Lovejoy confirming that my snippet works correct in the Chronos implementation (which is not the standard date/time library). So, I'm still wondering why this is not the case in Chronology. I will definitely check out Chronos and Aconcagua now. Stupid me that I did not see that :-( Johan On 03 May 2011, at 22:51, Stéphane Ducasse wrote:
BTW johan did you also check aconcagua?
Stef
On May 3, 2011, at 7:25 PM, Johan Brichau wrote:
Hi,
I traced a bug when working with timespans to the following issue illustrated in the code snippet below. The last expression in the snippet yields false, although it should yield true (imho).
|start end span| start :=DateAndTime now. end := start + 1 hour. span := Timespan starting: start ending: end. (span intersection: span) = span --> false
I think that the intersection of a span with itself, should be itself. The origin of the problem is that Timespan>>intersection: creates a new timespan roughly as follows:
Timespan starting: aBegin ending: self end.
But Timespan>>end returns the end time of the timespan minus the clockprecision. As such, the intersecting span is a nanosecond shorter than the one we would expect. This eventually yields wrong results when working with timespans.
The real question now is: should the implementation of Timespan>>intersection be changed -or- should Timespan>>end really return the (non-included) end time (that was passed when constructing it)?
I sent this email to bugs@chronos-st.org, but a discussion here probably will not hurt either.
Best regards Johan Brichau
participants (3)
-
Brent Pinkney -
Johan Brichau -
Stéphane Ducasse