Add support to parse relative modifiers from date strings #57
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
My apologies for the long delay. This PR adds date modification parsing such as
2022-05-15 +1 month
. This PR added the core functionality toparse_relative_time
and integrated the functionality tolib.rs
, specificallypub fn parse_datetime
.This did require moving things around. Specifically
pub fn parse_datetime
is now solely responsible for parsing date strings instead of passing off parsing topub fn parse_datetime_at_date
which is what it did before. The reason for this change is thatparse_datetime_at_date
was awkward.Currently
pub fn parse_datetime
takes a date string and passes of the input topub fn parse_datetime_at_date
with an additionalLocal::now()
argument and does the actual parsing there. This is awkward because according to its current docsparse_datetime_at_date
takes strings such as+3 days
and performs the modification on the given inputDateTime
. Allegedly doing no date string parsing. But it did do parsing. In fact, it did mostly parsing and only really performed its documentation described behavior after trying parsing first. Almost like it was an after thought and not its primary responsibility. 90% of the behavior was ignoring itsDateTime<Local>
input because most of the time it was there just in case it was needed. This made integrating my new modification parsing awkward. I hope that all made sense.TLDR I moved the parsing out of
parse_datetime_at_date
and intoparse_datetime
to make its function consistent with its documentation. Nowparse_datetime_at_date
still parse strings such as+3 days
and only that.The rest is what should be as expected. This PR is to eventually address 3505 and is a more robust PR to my first attempt here.
Thank you for considering my PR. This was a big one so I fully anticipate a bit of feedback and requests for tweaks. Anyway, Happy New Year!