Re: DateTime::Span intersection inconsistencies

I'm still not clear on why the end of the set defaults to being open

If you want to break up an arbitrary domain into mutually exclusive, collectively exhaustive ranges, then half-open intervals are often easier to deal with (and reason about) than closed intervals. Consider real numbers, or floating point approximations thereto.

Update: Or, for that matter, time intervals. The DateTime interface implies you can specify nanosecond precision, but it doesn't preclude greater precision. If you restrict intervals to be closed, you cannot deal with times that fall between the end of one interval, and the start of the "next". With half-open intervals, there need not be a notion of "next", just a notion of "this is an acceptable place to start and/or end an interval".

Comment on Re: DateTime::Span intersection inconsistencies

Replies are listed 'Best First'.
Re^2: DateTime::Span intersection inconsistencies by ikegami (Patriarch) on Jul 02, 2011 at 02:43 UTC
The thirteenth hour of the day starts at 12:00 pm and lasts 60 minutes. Is 1:00 pm part of the thirteenth hour? No. According to you, the module would answer "yes" if it was easier to do so. Ease has nothing to do it. It's simply behaving correctly.	[reply]
Re^3: DateTime::Span intersection inconsistencies by jpl (Monk) on Jul 02, 2011 at 15:22 UTC
The thirteenth hour of the day starts at 12:00 pm and lasts 60 minutes. Is 1:00 pm part of the thirteenth hour? No. According to you, the module would answer "yes" if it was easier to do so. Ease has nothing to do it. It's simply behaving correctly. I was addressing the OP's question about why it might make sense to default time intervals to half-open, rather than closed intervals. Your comment tells me that you define a day as a half-open interval, and you choose to make midnight part of the "following day", not part of the "previous day", a decision I would agree with. In my corner of the world, anyway, we wouldn't get universal agreement on that decision, a proof, I suppose, that if you leave a definition (or interface) ill-defined, confusion will ensue. Where ease comes in is making an interface easy to use correctly, which can be tremendously difficult. From the discussion here, it is quite clear that the interface is not easy to reason about. That would not be fixed by making intervals default to being closed, nor would it be fixed (IMHO) by adding an option to paper over possible confusion by adding "fuzz".	[reply]
Re^4: DateTime::Span intersection inconsistencies by ikegami (Patriarch) on Jul 02, 2011 at 17:11 UTC
Your comment tells me that you define a day as a half-open interval, and you choose to make midnight part of the "following day" No, the parallel of what i said for days would be: if one defines a day to be 24 hours that starts at midnight, then midnight would be part of the following day. The people to which you refer define "day" differently, a period of time that starts at midnight and ends at the next midnight. I was addressing the OP's question I know you were trying to answer why it's "open by default" as the OP claimed in his question. The problem is that your answer accepted the premise of a default when there isn't one. I agree about you about the ease of defining span as `[...)`, but it's not the reason for some non-existing default.	[reply] [d/l]