Feature request: Add a Period data structure

[jwir3]

A Period data structure is similar to a Duration, except that it has a specific start date. For example, one might have a period of 21 days, starting from January 1, 2020, which would have a start date/time of 2020-01-01 00:00:00 and an end date/time of 2020-01-22 00:00:00. (Obviously, these don't have timezones/offsets, so they are more likely to be NaivePeriod objects.

I am working on an implementation for this in a branch of chrono. The reason I am thinking this might be useful within the chrono library itself is that, given a NaivePeriod object, we can then determine if there is overlap with another NaivePeriod, or whether it contains a NaiveDateTime. I personally am working on a scheduling app, and thus this is a useful use case for me. That said, I'm not sure it belongs within the chrono library - perhaps a separate, add-on library would be more useful.

Thanks for your feedback!

[liquidscorpio]

Sounds interesting! Have you thought about the public API interface of the feature? If yes, would it be possible for you to share the same?

[quodlibetor]

Yes, a Period (built on top of some sort of TimeSpan that is like a duration but can be negative) is something that is very much wanted inside of chrono!

If you feel like putting in-progress work up I would be happy to review/collaborate on it before it's ready for inclusion.

[jwir3]

@liquidscorpio :

Sounds interesting! Have you thought about the public API interface of the feature? If yes, would it be possible for you to share the same?

Yes. For my purposes, a NaivePeriod (i.e. a Period without a timezone/offset) fulfills my needs. I wrote a fairly quick add-on library here: www.github.com/jwir3/chrono_period. Specifically, the API looks something like this:

https://docs.rs/chrono_period/0.1.0/chrono_period/struct.NaivePeriod.html

Right now, I've only added the method implementations for get_intersection_with() and intersects_with() (the latter being a call that utilizes the former to return a simple true/false value).

@quodlibetor :

Yes, a Period (built on top of some sort of TimeSpan that is like a duration but can be negative) is something that is very much wanted inside of chrono!

So Duration can't be negative right now? That seems fine. I wanted to avoid the use of the term TimeSpan, TimePeriod, etc... because I thought it was too overloaded with the difference between Date and Time (e.g. can a TimeSpan only be in HH:MM:SS format, like the other structs in chrono that have the prefix Time, or can it include dates, as well?)

My implementation actually uses two NaiveDateTime instances, one to indicate the start and one to indicate the end, and since chonometrics are necessarily ordered, I thought that enforcing the constraint that start is always before end is important. In other words, if you wanted to set up a Period with a negative Duration, then, it would actually invert the start and end members.

If you feel like putting in-progress work up I would be happy to review/collaborate on it before it's ready for inclusion.

Sure, I can certainly do that. I originally added it as a new period.rs file in the native module of chrono, and then thought that perhaps it would add clutter to the chrono library, so I removed it and added it as an add-on library. I can add it back. I think that starting with NaivePeriod, and later extending it to a period that isn't dependent on NaiveDateTimes, but rather just DateTimes is a good approach. I suppose I could make it generic - i.e. something like Period<NaiveDateTime> vs. Period<DateTime>, but I don't think this is the way that chrono has established itself so far.

[liquidscorpio]

Yes. For my purposes, a NaivePeriod (i.e. a Period without a timezone/offset) fulfills my needs. I wrote a fairly quick add-on library here: www.github.com/jwir3/chrono_period. Specifically, the API looks something like this:

Looks pretty neat! I am in need of something similar and going to explore if I can build off your work here.

[jwir3]

@liquidscorpio @quodlibetor I've created #384 as a starting point. Would you mind giving feedback on the code and what you think it needs to be included?