Fallback to using DateTimeOffset.TryParse if normal parsing doesn't work #118
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.
This pull request enhances the date math parsing logic to support explicit date expressions as a fallback when standard date math parsing fails. Now, expressions like
"2023-01-01"
or"2023-06-15T14:30:00"
are accepted and parsed correctly, with appropriate handling of time zones and end-of-day adjustments for upper limits. The update also significantly expands and improves the test coverage for these scenarios.Date parsing enhancements:
DateMath.TryParse
andIsValidExpression
to attempt parsing as an explicit date when date math parsing fails, supporting bothDateTimeOffset
andTimeZoneInfo
contexts. This ensures that plain date strings (with or without time zone info) are now accepted and parsed correctly. [1] [2] [3]Test coverage improvements:
DateMathTests.cs
to:||
anchor, verifying correct offset handling for both explicit and implicit time zones. [1] [2]These changes make date parsing more robust, user-friendly, and consistent across different usage scenarios.