Add support to parse relative modifiers from date strings#57
Closed
dcechano wants to merge 3 commits intouutils:mainfrom
Closed
Add support to parse relative modifiers from date strings#57dcechano wants to merge 3 commits intouutils:mainfrom
dcechano wants to merge 3 commits intouutils:mainfrom
Conversation
Contributor
|
sorry but it needs rebasing :( |
|
@dcechano picking this back up? Or found an alternative? |
Author
Unfortunately, I'm wayy smooth brained to figure out how to resolve the merge conflicts. If you want to take a stab at it you are more than welcome to give it a go. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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_timeand integrated the functionality tolib.rs, specificallypub fn parse_datetime.This did require moving things around. Specifically
pub fn parse_datetimeis now solely responsible for parsing date strings instead of passing off parsing topub fn parse_datetime_at_datewhich is what it did before. The reason for this change is thatparse_datetime_at_datewas awkward.Currently
pub fn parse_datetimetakes a date string and passes of the input topub fn parse_datetime_at_datewith an additionalLocal::now()argument and does the actual parsing there. This is awkward because according to its current docsparse_datetime_at_datetakes strings such as+3 daysand 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_dateand intoparse_datetimeto make its function consistent with its documentation. Nowparse_datetime_at_datestill parse strings such as+3 daysand 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!