Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #325 +/- ##
==========================================
- Coverage 99.34% 97.60% -1.74%
==========================================
Files 21 21
Lines 4123 4264 +141
Branches 136 136
==========================================
+ Hits 4096 4162 +66
- Misses 26 101 +75
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:
|
| "hst" => Ok("-10"), | ||
| "h" => Ok("+8"), | ||
| "gst" => Ok("+4"), | ||
| "gst" => Ok("+10"), |
There was a problem hiding this comment.
gst +10 is Guam, but most people writing GST mean Gulf time (+4, Dubai), which is what we had. could you please explain why Guam wins here? it silently changes what users get today.
There was a problem hiding this comment.
Guam wins because it's the value GNU's own zone table assigns this token: GST is Guam Standard Time there, and date --debug -d "2026-06-15 12:00 GST" on GNU coreutils 9.10 reports parsed zone part: UTC+10. I take the point that most people writing GST mean Dubai, and this does silently change what they get today. The crate's documented scope is "we support the same subset as GNU date", so I went with GNU's reading. If you'd rather match common usage than GNU here, I'll put +4 back.
There was a problem hiding this comment.
please don't quote GNU :(
the licenses are incompatible ...
There was a problem hiding this comment.
Sorry about that :( you're right. I copied the table lines into two of the replies without thinking about the license side, and that was the wrong way to present the evidence. I've replaced them with the offsets stated plainly. The date --debug output is still there, and nothing quoted remains.
| ("mesz", off(false, 2, 0)), | ||
| ("mest", off(false, 2, 0)), | ||
| ("kst", off(false, 9, 0)), | ||
| // Each of these resolved to a different real meaning of the |
There was a problem hiding this comment.
the comment says "the one GNU date uses", but your PR description says GNU ignores a bare abbreviation entirely. please fix it and make it one line, thanks.
There was a problem hiding this comment.
Thanks, fixed. The comment is one line now, and the PR description is corrected to match.
| ("ast", off(true, 4, 0)), // Atlantic Standard, was -3 | ||
| ("bst", off(false, 1, 0)), // British Summer, was +6 | ||
| ("gst", off(false, 10, 0)), // Guam Standard, was +4 | ||
| ("sst", off(true, 11, 0)), |
There was a problem hiding this comment.
sst is the only one without a note, and it's the contested one. a short comment on why it stays at -11 would help.
There was a problem hiding this comment.
SST is now -12, with a note on the line. The GNU reading comes from GNU's own zone table, where SST is Samoa Standard Time, confirmed by date --debug (parsed zone part: UTC-12). The -11 came from tzdata's Pacific/Pago_Pago, but for these tokens the operative reference is GNU's zone table, so -12 it is.
| // Each of these resolved to a different real meaning of the | ||
| // abbreviation than the one GNU date uses, e.g. BST as Bangladesh | ||
| // Standard Time rather than British Summer Time. | ||
| ("adt", off(true, 3, 0)), // Atlantic Daylight, was +4 |
There was a problem hiding this comment.
could you please also add a test in tests/ going through parse_datetime, like "2026-06-15 12:00 BST"? that's the actual user-facing bug.
There was a problem hiding this comment.
Thanks, done. Added the tests in tests/date.rs; they go through parse_datetime and cover all five abbreviations.
ARMeeru
changed the title
2 participants
timezone_name_to_offsetdocuments its own scope as matching GNU:This is the follow-up to #321, which measured the crate against GNU across 100 candidate abbreviations and found five where both accept the name but the offsets disagree. This PR corrects all five to the offsets GNU date assigns them, each a real behaviour fix for current users:
ADT-3 (was +4)AST-4 (was -3)BST+1 (was +6)GST+10 (was +4)SST-12 (was -11)For example,
parse_datetime("2026-06-15 12:00 BST")currently returns +06:00, which is Bangladesh Standard Time, where GNU says BST is +1 (British Summer Time).How the offsets were verified
Confirmed with GNU date 9.10:
date --debug -d "2026-06-15 12:00 BST"reportsparsed zone part: UTC+01, and likewise +10, -04, -03 and -12 for GST, AST, ADT and SST.One correction to an earlier version of this description: it said GNU ignores a bare abbreviation token entirely. That was wrong, and came from reading
date's printed output, which renders in the system default zone so the token looks ignored. The epoch math and--debugshow the parser does apply the abbreviation's offset.Tests assert the five corrected values through
parse_datetimeintests/date.rsand fail without the fix.