fix(offset): accept MEZ, MESZ, MEST and KST abbreviations - #321
Conversation
Sorry, something went wrong.
The table is meant to cover the same abbreviations GNU date supports, but these four were missing, so `date -d "2024-01-15 12:00 MEZ"` failed here while GNU accepts it. Offsets were measured against GNU coreutils: MEZ is +1, MESZ and MEST are +2, and KST is +9. Downstream this is what pushes uutils/coreutils to keep its own abbreviation table in date.rs and parse the string in fragments, which is the root of uutils/coreutils#13865.
Codecov Report✅ All modified and coverable lines are covered by tests. @@ Coverage Diff @@
## main #321 +/- ##
=======================================
Coverage 99.33% 99.33%
=======================================
Files 21 21
Lines 4051 4061 +10
Branches 129 129
=======================================
+ Hits 4024 4034 +10
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 Harness.
|
Sorry, something went wrong.
Merging this PR will degrade performance by 3.66%⚠️ Different runtime environments detected
❌ 1 regressed benchmark Warning Please fix the performance issues or acknowledge them on CodSpeed. Performance Changes
Tip Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent. Comparing ARMeeru:fix/missing-gnu-timezone-abbreviations (5266ff2) with main (46fb737) |
Sorry, something went wrong.
timezone_name_to_offset documents its own scope as matching GNU:
Four abbreviations GNU accepts are missing from the table, so they fail here:
MEZ is +1, MESZ and MEST are +2, and KST is +9.
How these four were picked
Rather than adding only the ones I happened to run into, I compared the crate against GNU across 100 candidate abbreviations: everything already in this table, plus the ones uutils/coreutils carries in date.rs, plus a spread of common world abbreviations. GNU accepted 72 of them and the crate agreed on 63. The other nine fall into two groups.
Four the crate rejects outright. Those are in this PR.
Five where both accept but the offsets disagree: ADT, AST, BST, GST and SST. Every one of those is a genuinely ambiguous name (Atlantic or Arabia, British or Bangladesh, Gulf or Guam), and changing a value that already exists is a different sort of decision from filling a hole. I left them alone. Happy to open an issue with the measurements if you want them tracked.
Where the offsets came from
Each one was measured by running GNU date and comparing instants, for example:
GNU coreutils 9.1. These came from running GNU date and reading its output, not from reading its source.
Tests
The four are added to the existing timezone_name_without_offset list. That test fails before the change and passes after. The rest of the suite is unaffected.
Context
This gap is part of why uutils/coreutils keeps a separate abbreviation table in date.rs, which came up in uutils/coreutils#13865. This change does not remove that table on its own, and the two are independent.