date, touch: fix parse_datetime 0.13.0 compatibility (#8754) #8843
Conversation
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
naoNao89
force-pushed
the
fix-parse-datetime-update
branch
from
e1d88e3 to
4340913
Compare
|
GNU testsuite comparison: |
naoNao89
force-pushed
the
fix-parse-datetime-update
branch
2 times, most recently
from
3371f17 to
3e1d11c
Compare
|
GNU testsuite comparison: |
naoNao89
force-pushed
the
fix-parse-datetime-update
branch
from
3e1d11c to
da6ede1
Compare
|
GNU testsuite comparison: |
naoNao89
force-pushed
the
fix-parse-datetime-update
branch
from
da6ede1 to
d55a0ee
Compare
|
GNU testsuite comparison: |
|
@naoNao89 ping ? :) |
Fixes uutils#8754 parse_datetime 0.13.0 fixes the bug where parsing large second values like "12345.123456789 seconds ago" would fail with "invalid date". However, parse_datetime 0.13.0 introduced a breaking API change: - Old (0.11.0): Returns chrono::DateTime - New (0.13.0): Returns jiff::Zoned This commit adapts both date and touch utilities to work with the new API: date.rs changes: - Simplified parse_date() to directly return jiff::Zoned - Removed unnecessary chrono -> jiff conversion code - parse_datetime now returns the exact type date utility uses - Added detailed comments explaining the API change and issue uutils#8754 touch.rs changes: - Added jiff::Zoned -> chrono::DateTime conversion in parse_date() - Changed from parse_datetime_at_date to parse_datetime - Marked ref_time parameter as unused (preserved for future use) - Added detailed comments about API change and future migration path Note: 3 integration tests fail due to timezone handling changes in parse_datetime 0.13. These are separate issues that will be addressed in follow-up commits.
…ates The previous implementation incorrectly used parse_datetime() instead of parse_datetime_at_date(), causing relative date strings like 'yesterday' or '2 days ago' to be calculated from the current system time instead of the caller-specified reference time. This fix: - Uses parse_datetime_at_date() with proper chrono->jiff->chrono conversions - Restores deterministic behavior for relative date parsing - Adds jiff 0.2.15 as direct dependency (not workspace) to avoid feature conflicts - Ensures tests/touch/relative passes in CI Note on jiff dependency: parse_datetime 0.13 depends on jiff ^0.2.15 with specific features. Adding jiff via workspace dependency causes feature unification conflicts across platforms. Using a direct dependency with version 0.2.15 resolves this while maintaining compatibility with parse_datetime's requirements.
sylvestre
force-pushed
the
fix-parse-datetime-update
branch
from
d55a0ee to
980fc7f
Compare
CodSpeed Performance ReportMerging #8843 will degrade performances by 3.01%Comparing Summary
Benchmarks breakdown
Footnotes
|
sylvestre
force-pushed
the
fix-parse-datetime-update
branch
from
a93985d to
149c7a6
Compare
|
GNU testsuite comparison: |
This was referenced Oct 27, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Fixes #8754
Problem
The
datecommand fails with "invalid date" when parsing large second values with nanoseconds: