Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #272 +/- ##
=======================================
Coverage 99.29% 99.30%
=======================================
Files 20 20
Lines 3847 3894 +47
Branches 121 122 +1
=======================================
+ Hits 3820 3867 +47
Misses 26 26
Partials 1 1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@abhishekpradhan wdyt ? :) |
There was a problem hiding this comment.
Looks good overall. I left one inline note on the new Display behavior, since it seems to drop subsecond precision at the moment, but the rest of the follow-up cleanup makes sense to me. With this work completed, I think #160 is effectively resolved as well. 🙂
Provide a standard formatting path so callers (and tests) can use `.to_string()` instead of hand-rolling offset formatting everywhere.
Document that expect_in_range is intended for tests/trusted contexts and that Extended values never compare equal to a Zoned.
The Timestamp variant was #[cfg(test)]-gated dead code outside tests. The parse_timestamp function already calls set_timestamp on the builder directly, bypassing the TryFrom<Vec<Item>> path. Remove the variant and refactor builder tests to exercise set_timestamp directly instead.
Replace hand-rolled format_offset_colon / format_for_assert helpers with the new Display impls. Replace local expect_in_range_datetime test helpers with ParsedDateTime::expect_in_range().
Add a dedicated fuzz_large_year target with structured inputs biased toward large years (near 9999 boundary, up to GNU_MAX_YEAR). Keep the original fuzz_parse_datetime target unchanged for raw-bytes fuzzing.
When nanoseconds are non-zero, include them in Display output as `.NNNNNNNNN` between seconds and the offset. This avoids silently dropping sub-second precision from the formatted representation.
abhishekpradhan
left a comment
abhishekpradhan
left a comment
There was a problem hiding this comment.
Great, I think we’re good to go here. I left one minor nit on the README example, but otherwise this looks good to me.
| ```rs | ||
| use parse_datetime::{parse_datetime, ParsedDateTime}; | ||
|
|
||
| let dt = parse_datetime("12000-01-01").unwrap(); |
There was a problem hiding this comment.
Nit: this may not always end with +00:00, since it depends on the local timezone.
Merging this PR will improve performance by 3.6%
Performance Changes
Comparing 
|
2 participants
see #263