Repository navigation
fix(builder): handle wall-clock times in a DST gap like GNU date - #346
jayhemnani9910 wants to merge 1 commit into
Conversation
A date or time that falls in the local zone's DST gap was moved past the
gap by jiff (2024-03-10 02:30 in New York became 03:30). GNU date
rejects it as an invalid date, so do the same. A time written with its
own zone ("2024-03-10 02:30 UTC", "...T02:30:00Z") was built in the
local zone first and so came out an hour late; apply the zone to the
wall-clock time as written. A relative item that lands in a gap still
moves past it, as in GNU.
There was a problem hiding this comment.
Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.
An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing. Review the Copilot code review billing settings.
Merging this PR will degrade performance by 4.36%2 warnings
Warning Please fix the performance issues or acknowledge them on CodSpeed. Performance Changes
Tip Investigate this regression by commenting Comparing 
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #346 +/- ##
=======================================
Coverage 98.89% 98.90%
=======================================
Files 21 21
Lines 4540 4567 +27
Branches 142 144 +2
=======================================
+ Hits 4490 4517 +27
Misses 49 49
Partials 1 1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Two problems with times in a DST gap (New York skips 02:00-03:00 on 2024-03-10):
The first is a time that doesn't exist; jiff's default disambiguation moves it past the gap, and GNU rejects it. The second is wrong by an hour: the date and time are first placed in the local zone, where 02:30 doesn't exist and becomes 03:30, and only then is the written zone applied to that wall clock.
02:30ZandT02:30:00Zare affected too;02:30 +00:00was already right because the time's own offset is applied first.build_in_rangenow keeps the wall-clock time the input asked for. If the local zone moved it, the input named a time in a gap and is rejected. If the input carries a zone (UTC,Z, an offset), that zone is applied to the requested wall-clock time instead of the locally resolved one. A relative item that lands in a gap (2018-11-03 +1 dayin Sao Paulo) still moves past it, as GNU does, and times in the repeated hour still take the first offset.Tests:
test_local_time_in_dst_gap_is_invalid,test_dst_gap_neighboursandtest_relative_item_moves_past_dst_gapintests/date.rs; 5 of the 9 cases fail on main.cargo test: 491 passed; clippy and fmt clean. 22 inputs in 6 zones (New York, Sao Paulo, Berlin, Lord Howe, Kolkata, UTC), covering gaps, the repeated hour, written zones and offsets, weekdays and relative items, give the same instant or error as GNU date 9.7.