✨ Add a NaivePeriod data structure. #384
Conversation
A NaivePeriod covers the period of time between two NaiveDateTime(s), inclusive. This data structure can be used to intersect two NaivePeriods to determine if they overlap. This is in partial fulfillment of chronotope#380, but does not provide necessary code to handle DateTime objects (with offsets). Refs chronotope#380.
| @@ -440,7 +440,7 @@ pub use oldtime::Duration; | |||
| #[cfg(feature="clock")] | |||
| #[doc(no_inline)] pub use offset::Local; | |||
| #[doc(no_inline)] pub use offset::{TimeZone, Offset, LocalResult, Utc, FixedOffset}; | |||
| #[doc(no_inline)] pub use naive::{NaiveDate, IsoWeek, NaiveTime, NaiveDateTime}; | |||
| #[doc(no_inline)] pub use naive::{NaiveDate, IsoWeek, NaiveTime, NaiveDateTime, NaivePeriod}; | |||
There was a problem hiding this comment.
I'm tempted to keep this out of the root namespace and put the period module behind an unstable feature flag for a month or two before it's released with back-compat guarantees. I might change my mind much faster than that, though, or be convinced otherwise.
| @@ -455,7 +455,7 @@ pub mod prelude { | |||
| #[cfg(feature="clock")] | |||
| #[doc(no_inline)] pub use Local; | |||
| #[doc(no_inline)] pub use {Utc, FixedOffset}; | |||
| #[doc(no_inline)] pub use {NaiveDate, NaiveTime, NaiveDateTime}; | |||
| #[doc(no_inline)] pub use {NaiveDate, NaiveTime, NaiveDateTime, NaivePeriod}; | |||
There was a problem hiding this comment.
Same here keeping it out of the prelude at least at the beginning.
| pub start: NaiveDateTime, | ||
|
|
||
| /// The date at which the period ends. This is inclusive, meaning that the period runs up to | ||
| /// and including this date/time. | ||
| pub end: NaiveDateTime |
There was a problem hiding this comment.
We should keep these private, and require a constructor.
| /// As such, if you need to interset two time periods that are of differing time zones, you're out | ||
| /// of luck (patches accepted, though). | ||
| #[derive(PartialEq, Eq, PartialOrd, Ord, Copy, Clone, Debug)] | ||
| pub struct NaivePeriod { |
There was a problem hiding this comment.
Can we accomplish a bit more future compatibility and smaller api surface with a Period<T: Datelike + Timelike>? I'd rather reduce the number of places that chrono distinguishes between Naive and tz-aware types. Putting this behind an unstable flag will allow a punt on this for awhile.
| pub fn new(start: NaiveDateTime, end: NaiveDateTime) -> Self { | ||
| NaivePeriod { start: start, end: end } |
There was a problem hiding this comment.
Is it reasonable for us to verify that start < end or start <= end? Maybe rename to left, right and just put them in the right order?
|
|
||
| use std::cmp::{min, max}; | ||
|
|
||
| /// A period of time between two ISO 8601 dates/times ([NaiveDateTime](NaiveDateTime)s). |
There was a problem hiding this comment.
fwiw I think docs links only work on nightly, and docs.rs builds on nightly, so all links could be changed from the [..](..) to be just [..]. Separately, stylistically, I slightly prefer all docs links to just be simple names with backticks: e.g.
[`NaiveDateTime`]
NOTE: This is a work in progress, it's not quite ready to be merged yet I don't think.
A NaivePeriod covers the period of time between two NaiveDateTime(s),
inclusive. This data structure can be used to intersect two NaivePeriods to
determine if they overlap.
This is in partial fulfillment of #380, but does not provide necessary code
to handle DateTime objects (with offsets).
Refs #380.