Conversation
Merging this PR will degrade performance by 3.2%
|
| Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|
| ❌ | parse_invalid_input |
59 µs | 61 µs | -3.28% |
| ❌ | parse_epoch_timestamp |
14.8 µs | 15.2 µs | -3.12% |
Tip
Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.
Comparing sap1110:fix-weekday-with-explicit-date (b0c0424) with main (e25bf15)
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #335 +/- ##
==========================================
- Coverage 97.48% 97.32% -0.17%
==========================================
Files 21 21
Lines 4258 4261 +3
Branches 136 137 +1
==========================================
- Hits 4151 4147 -4
- Misses 106 113 +7
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:
|
When the input carries both a weekday and a calendar date, the date is now authoritative and the weekday is dropped, matching GNU date. This also covers ordinal forms such as "next friday sep 25 2026". Relative items are still applied on top of the date, and a weekday without a date behaves as before. Closes uutils#317
63edbf2 to
b0c0424
Compare
|
Quick update: I looked at GNU's source before writing the first version, and I shouldn't have. I've thrown that version out and rewritten it from scratch. This time I only ran GNU date and checked what it does. The new version is force-pushed. |
If you gave the parser a weekday and a date that didn't match, it moved the date to fit the weekday. August 17 2026 is a Monday, so
Wednesday August 17 2026should give Aug 17, but it gave Wed Aug 19.Now the date wins and the weekday is ignored, which is what GNU date does.
Wednesday August 17 2026gives Mon Aug 17.This works for:
next,lastand ordinal weekdays.next Friday Sep 25 2026now gives Sep 25, which also fixes the case in coreutils #14681.These still work the same:
+1 dayornext weekare applied after the date.wed,wed 10:30) behaves as before.The fix is one change in the builder: when a date is set, it clears the weekday. Because of that, the normal-year and large-year paths now behave the same.
I added a test with 22 cases, all checked against GNU date. 18 of them fail without the fix. One existing unit test expected the old behaviour, so I updated it to match what GNU gives.
Closes #317