Support ranges about nodatime HOT 23 CLOSED

Period is good for local types (LocalDate, LocalDateTime, LocalTime).

Duration would be good for Instants. I'm not sure about either OffsetDateTime 
or ZonedDateTime (in the same way as we don't have arithmetic for them).

I think I'd probably *prefer* to put the methods on the start, e.g.

    foreach (var date in start.StepBy(period).TakeWhile(d => d < end))

Oh, and we might want to consider a way of iterating over time zone transitions 
in the same way. I've often used that - but it may be more useful for Noda Time 
developers than line-of-business app developers...

Original comment by jonathan.skeet on 11 Nov 2012 at 4:44

from nodatime.

Well, perhaps I'm opinionated on this, but I really think 2017-01-01 - 2017-01-04 can only be interpreted as "four days", while 2017-01-01T00:00:00Z - 2017-01-04T00:00:00Z can only be interpreted as "72 hours" (or "3 standard days").

I can't really think of any exceptions to this, other than human confusion around whether or not the time is a part of the data in question - but we've eliminated that in NodaTime by having separate types for LocalDate and Instant (and others).

from nodatime.

(as noted in #671, I'd be happier if the inclusivity of the range was a property of the type rather than the instance anyway: it seems less prone to mistakes.)

from nodatime.

We would also need to consider whether LocalDateRange(start, end) is inclusive 
or
exclusive of end. normally ranges are better if they are exclusive but with 
dates I'm
not so sure.

Also do we want to be able to have different increments (by month, by year, 
etc.).

Original comment by james.keesey on 17 Feb 2010 at 6:26

from nodatime.

Original comment by jonathan.skeet on 17 Mar 2012 at 9:21

• Added labels: V1-OutOfScope

from nodatime.

Original comment by malcolm.rowe on 13 Jul 2012 at 8:33

• Added labels: Type-Enhancement

from nodatime.

Original comment by malcolm.rowe on 30 Jul 2012 at 7:45

• Added labels: Milestone-unscheduled
• Removed labels: V1-OutOfScope

from nodatime.

James raised two good issues: having different increments and 
inclusive/exclusive ending  points.  

We already have the Period type which could handle by month, year, etc.  If we 
added an Enumerate (don't like the name) method to it, we could have the 
required functionality and let the API user determine what is the ending point.

Assuming `IEnumerable<LocalDate> Enumerate(LocalDate start)`, then we could do 
things like:

- foreach (var date in period.Enumerate(start).TakeWhile(d => d < end)) { ... }
- foreach (var date in period.Enumerate(start).TakeWhile(d => d <= end)) { ... }
- foreach (var date in period.Enumerate(start).Take(n)) { ... }

Original comment by makaretu on 11 Nov 2012 at 4:26

from nodatime.

StepBy generates a sequence of date/times by continually incrementing a start 
date/time with a step.
Stepping by zero raises a precondition exception. Underflow/Overflow terminates 
the sequence.

Added StepBy(Period) to LocalDate, LocalTime and LocalDateTime.
Added StepBy(Duration) to Instant.

OffsetDateTime and ZonedDateTime was not changed because we have not 
implemented arithmetic for the types.

First time I ever used the 'checked' keyword!

Original comment by makaretu on 12 Nov 2012 at 11:25

Attachments:

• StepBy.patch

from nodatime.

Is anyone considering pulling this change?

Original comment by makaretu on 2 Dec 2012 at 10:33

from nodatime.

I don't know about anyone else, but I don't have the bandwidth right now. I'm 
hoping to get back to Noda Time in the new year... although I really want to 
start off by focusing on the PCL and CLDR work. I'll see if I can take a quick 
look at this anyway though...

Original comment by [email protected] on 3 Dec 2012 at 8:20

from nodatime.

Some discussion here: 
http://stackoverflow.com/questions/20599006/how-do-i-accurately-represent-a-date
-range-in-nodatime

Original comment by malcolm.rowe on 16 Dec 2013 at 11:48

from nodatime.

We probably want to do some sort of DateRange for 2.0 - amongst other benefits, 
it would cover issue 297.

Original comment by jonathan.skeet on 26 Jun 2014 at 5:33

• Added labels: Milestone-2.0-consider
• Removed labels: Milestone-unscheduled

from nodatime.

This is implemented as DateInterval. Leaving this open to review the API.

from nodatime.

@jskeet Date intervals are normally closed intervals, i.e. both endpoints should be included. @mj1856 should be able to confirm.

from nodatime.

@lundmikkel: I think it can be useful to have the ability to treat them as half-closed, e.g. to make it clear that a sequence of intervals is contiguous. (e.g. "1st of January (inclusive) to 1st February (exclusive), then 1st February (inclusive) to 1st March (exclusive)") The current DateInterval allows both... do you think that causes any problems? It does mean users need to be aware that it can be used both ways, admittedly.

from nodatime.

I find that people often get confused about interval endpoint inclusion. For certain interval types, only/mainly one type of endpoint inclusion makes sense. E.g. time intervals are half-open (as with Interval), date intervals are closed. That doesn't necessarily mean that that is the only way to consider them, but keeping to a "standard" would be nice.

I have previously done an extensive interval collection library, and we found that doing endpoint inclusion explicit was the best help for users. It also makes algorithms, e.g. for overlap or containment, easier since they can be considered more generally.

To get back to DateInterval, I think calling it Inclusive is asking for trouble. It isn't clear what kind of inclusion it is, unless you read the documentation, which states that it only is the last endpoint. My suggestion is to name it explicitly, e.g. 'EndInclusive', or only allow one type of interval, e.g. closed.

Another possible approach is the one we took, where the interval is generic and allows for all types of endpoint inclusion, but I haven't looked enough at DateInterval to say if that makes sense.

from nodatime.

I would definitely be happy with EndInclusive instead of Inclusive. But I think there are sufficient situations where you do want an exclusive end point for a date range that it's worth keeping that available. (I don't think it would make sense for a regular Interval to be customizable like that though.)

from nodatime.

Well, I'd always express a half-open interval as [2017-01-01, 2017-01-04) to be clearer :)

The use case I find compelling is when you're thinking in terms of dates, but you want to have an abutting sequence of date intervals, e.g.

• [2017-01-01, 2017-02-01)
• [2017-02-01, 2017-03-01)
• [2017-03-01, 2017-04-01)
• [2017-04-01, 2017-05-01)

I find it easier to check that intervals are abutting by knowing that the end of one should be the same as the start of the other than to have to add a day. (It would be particularly easy to get leap years wrong here, for example.)

from nodatime.

I can't remember the discussion I had with @malcolmr about using different types for this, but possible compromise solution - 3 types:

• IDateInterval interface, with the same public members as the current DateInterval
• DateInterval class which is always end-inclusive
• EndExclusiveDateInterval which is always end-exclusive

The current ContainedDatesDateIntervalEqualityComparer could implement IEqualityComparer<IDateInterval>; NormalizingDateIntervalEqualityComparer would only be relevant to EndExclusiveDateInterval as DateInterval could never be empty.

Basically, those who never need to deal with an end-exclusive date interval could just use DateInterval (with the bias towards that being shown in the name) but for the uses as in my earlier comment, we could use EndExclusiveDateInterval.

Thoughts?

from nodatime.

I would seriously only have a DateInterval with both endpoints included. I don't see any real benefits from allowing both endpoint inclusion types. Quite the contrary actually: I think it only confuses the user even more.

I not sure about your example, @jskeet. If you wanted to create a half-open interval, then a factory method could be the solution. If it was for readability, then maybe the ToString/DebuggerDisplay could print month names instead of the specific dates. For instance (for some locale):

• [2017-01-01;2017-01-04] could print something like "January 1st, 2017 - January 4th, 2017"
• [2017-01-01;2017-01-31] could print something like "January, 2017"
• [2017-01-01;2017-12-31] could print something like "2017"

from nodatime.

@lundmikkel: That would assume that every use case for an interval that happens to cover every day of a month is the same. Maybe I've got a set of intervals that is meant to be February 1st to February 28th each year, exactly 28 days... it would be odd for that to show differently in leap years to non-leap-years.

However, the fact that everyone else seems to think the use case I'm concerned with is irrelevant does make me want to give in. @malcolmr - apologies for the fact that we'll be wasting a lot of the comparer work you did, if we do indeed make these always-inclusive.

from nodatime.

@malcolmr: Yup, hence my alternative proposal a few comments ago - but it sounds like Mikkel and Matt are pretty sure that the speculated EndInclusiveDateInterval type just shouldn't exist. I suppose we can always add that (and the interval) later...

from nodatime.