-
Notifications
You must be signed in to change notification settings - Fork 537
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Datelike
should have methods to add/sub a number of calendar day/month/year
#290
Comments
I have a similar issue. I just want to get the next/last day out of a fn next_date<T: Datelike + Copy>(date: T, fwd: bool) -> T {
let inc: i32 = {
if fwd {
1
} else {
-1
}
};
match date.with_ordinal((date.ordinal() as i32 + inc) as u32) {
Some(dt) => dt,
None => {
if fwd {
date
.with_year(date.year() + 1).unwrap()
.with_ordinal(1).unwrap()
} else {
date
.with_year(date.year() - 1).unwrap()
.with_month(12).unwrap()
.with_day(31).unwrap()
}
}
}
} |
I would like to substract NaiveDate from DateTime. |
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Datelike
currently offers a set ofwith_*()
methods to set the day/month/year, but the resulting date must be valid (for example callingwith_month(13)
doesn't translate to january of the next year). You can also add aDuration
to aDatelike
, but there's no goodDuration
value for year/month/day because of leap years, various month lengths, and DST.I'd like to have methods
add_days/month/years(i32) -> Self
to easily add/subtract the corresponding number of time units. Might want to haveadd_hour/min/sec/etc()
for consistency's sake, although adding aDuration
works well in this case (unless we want to handle DST ?).My usecase is deceptively simple: I write a report and want to know when the next day/week/month/year starts, after a given timestamp. For example I have
2018-11-14T12:34:56z
as input and want2018-12-14T00:00:00z
as output (beginning of next month).This is ugly but doable for "next year":
But the implementation for
next_month/week/day()
is not going to be fun.Incidentally, it with also be nice to have a
with_year/month/day/etc()
that panics instead of returning a result, for cases like this where the input is hardcoded and known to be correct. Or awith_ymd()
andwith_hmsn()
;)The text was updated successfully, but these errors were encountered: