Fix timezone parsing bug in date command #8992
Open
+152
−7
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
Fixes issue where dates without timezone info (like '2025-03-29 8:30:00') were interpreted as UTC instead of local time, causing 1-hour offset errors. The fix parses common date formats as naive datetimes first, then converts to local time using Local.from_local_datetime(), which correctly applies the timezone offset for that specific date (not the current date's offset). This matches GNU date behavior and fixes the issue reported in: - uutils#8976 - cockpit-project/bots#8345 - cockpit-project/bots#8373
Adds test_date_timezone_parsing_fix() that verifies the fix for issue uutils#8976. The test ensures dates without timezone are interpreted as local time for that specific date, not as UTC converted to local time. Tests cover: - Europe/Prague timezone (CET/CEST transitions) - Standard time vs daylight saving time - Multiple date formats - Different timezones (America/New_York) This prevents regression of the timezone parsing bug.
Add detailed documentation explaining that the current chrono-based timezone parsing fix is a temporary bandaid solution that: 1. Reintroduces chrono dependencies (conflicts with jiff migration) 2. Fixes critical bug uutils#8976 affecting real users 3. Needs proper jiff-native implementation 4. Includes clear migration plan and risk mitigation This ensures future maintainers understand the trade-offs and have a clear path forward for the proper implementation.
Apply standard Rust formatting to: - Align comments and improve readability in parse_date function - Format test function calls for better parameter visibility - Remove trailing whitespace No functional changes, just code style improvements.
naoNao89
force-pushed
the
fix-date-timezone-parsing
branch
from
ff1ec6c to
7e83262
Compare
|
GNU testsuite comparison: |
naoNao89
force-pushed
the
fix-date-timezone-parsing
branch
2 times, most recently
from
b337b5b to
ee84054
Compare
CodSpeed Performance ReportMerging #8992 will improve performances by 5.03%Comparing Summary
Benchmarks breakdown
Footnotes
|
naoNao89
force-pushed
the
fix-date-timezone-parsing
branch
4 times, most recently
from
2f2a610 to
5dd6c8b
Compare
|
GNU testsuite comparison: |
naoNao89
force-pushed
the
fix-date-timezone-parsing
branch
from
5dd6c8b to
a7acbe2
Compare
- Use fixed offset timezone to preserve chrono's exact timezone calculation - Avoids Windows vs Unix timezone database differences in DST transitions - Documents critical case: Windows CI interprets dates incorrectly due to different DST rules - Trade-off: %Z shows numeric offset (+0100) instead of timezone abbreviation (CET) - Updates tests to expect numeric offsets for cross-platform consistency This ensures consistent behavior across all platforms by using chrono's precise timezone calculations instead of relying on system timezone databases.
naoNao89
force-pushed
the
fix-date-timezone-parsing
branch
from
a7acbe2 to
f4eafa4
Compare
|
GNU testsuite comparison: |
…ndows When parsing dates without explicit timezone, verify that the system timezone offset (from jiff) matches chrono's calculation. If offsets differ due to different DST rules (especially on Windows), adjust the timestamp to ensure the displayed time remains correct while preserving timezone abbreviations. This fixes the Windows CI test failure where the time was off by an hour or the timezone showed as UTC instead of CET for dates like '2025-01-15 8:30:00' with TZ=Europe/Prague environment variable set.
naoNao89
force-pushed
the
fix-date-timezone-parsing
branch
from
cc73169 to
d79e38f
Compare
|
GNU testsuite comparison: |
|
GNU testsuite comparison: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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: #8976
found this annoying bug where
date --date="2025-03-29 8:30:00"was showing07:30:00 CETinstead of08:30:00 CET. Turns out the parser was treating dates without timezone as UTC, then converting to local time. But GNU date treats them as already local time.The fix: Parse common date formats as naive datetimes first, then convert to local time using the correct timezone for that specific date. Falls back to existing parser for complex stuff like "tomorrow".
Used git blame to understand the jiff migration 301e33c and ensure our changes don't conflict with existing architecture. This is a temporary bandaid until jiff-native implementation.