fix(offset): correct ADT, AST, BST, GST and SST to GNU's values by ARMeeru · Pull Request #325 · uutils/parse_datetime

ARMeeru · 2026-08-31T06:07:46Z

timezone_name_to_offset documents its own scope as matching GNU:

GNU date only supports a subset of these. We support the same subset as GNU date.

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" reports parsed 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 --debug show the parser does apply the abbreviation's offset.

Tests assert the five corrected values through parse_datetime in tests/date.rs and fail without the fix.

codecov · 2026-08-31T06:24:42Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.70%. Comparing base (3fc6d60) to head (000c30d).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #325      +/-   ##
==========================================
+ Coverage   97.58%   97.70%   +0.11%     
==========================================
  Files          21       21              
  Lines        4389     4395       +6     
  Branches      138      138              
==========================================
+ Hits         4283     4294      +11     
+ Misses        105      100       -5     
  Partials        1        1

Flag	Coverage Δ
macos_latest	`97.70% <100.00%> (+0.11%)`	⬆️
ubuntu_latest	`97.70% <100.00%> (+0.11%)`	⬆️
windows_latest	`12.40% <0.00%> (-0.02%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

sylvestre · 2026-09-22T09:56:18Z

        "hst" => Ok("-10"),
        "h" => Ok("+8"),
-        "gst" => Ok("+4"),
+        "gst" => Ok("+10"),


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.

Guam wins because it's the value GNU date gives this token: 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.

please don't quote GNU :(
the licenses are incompatible ...

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.

sylvestre · 2026-09-22T09:56:26Z

            ("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


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.

Thanks, fixed. The comment is one line now, and the PR description is corrected to match.

sylvestre · 2026-09-22T09:56:42Z

+            ("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)),


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.

SST is now -12, with a note on the test line. The -12 is what GNU date gives: date --debug reports parsed zone part: UTC-12. The -11 came from tzdata's Pacific/Pago_Pago, but for these tokens the reference is GNU date, so -12 it is.

sylvestre · 2026-09-22T09:56:51Z

+            // 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


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.

Thanks, done. Added the tests in tests/date.rs; they go through parse_datetime and cover all five abbreviations.

codspeed · 2026-10-11T06:19:14Z

Merging this PR will improve performance by 3.46%

⚠️

9 benchmarks spent significant time in system calls

System calls cannot be consistently instrumented, so they are not included in the measure, which understates the real cost. Please switch to the Walltime instrument to accurately measure system calls.

Measurement and system calls

parse_date_slash_format

parse_date_only

parse_now

parse_iso_datetime

parse_extended_large_year

parse_extended_year

parse_tomorrow

parse_yesterday

parse_epoch_timestamp

⚠️

Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 1 improved benchmark
✅ 20 untouched benchmarks

Performance Changes

	Benchmark	`BASE`	`HEAD`	Efficiency
⚡	`parse_weekday`	42.7 µs	41.3 µs	+3.46%

Tip

Curious why performance improved? Comment @codspeedbot explain why performance improved on this PR, or directly use the CodSpeed MCP with your agent.

_{Comparing ARMeeru:fix/gnu-timezone-abbreviation-offsets (000c30d) with main (3fc6d60)}

The table is meant to cover the same abbreviations GNU date supports, but five of them resolved to a different offset than GNU date gives, so "2026-06-15 12:00 BST" parsed as +06:00 (Bangladesh) rather than +01:00 (British Summer Time). Offsets were measured with `date --debug` on GNU coreutils 9.10: ADT is -3, AST -4, BST +1, GST +10 and SST -12.

ARMeeru · 2026-10-11T06:28:26Z

@sylvestre rebased onto main after #332 and squashed into one commit. The five values are unchanged.

I couldn't reproduce the CodSpeed regression locally: parse_weekday stays within 1% of main (639 ns vs 643 ns, averaged over two runs).

The open question is still GST: I went with +10 to match GNU date, but if you'd rather keep Dubai's +4, I'll switch it back.

sylvestre · 2026-10-11T07:23:18Z

@codspeedbot fix this regression

codspeed · 2026-10-11T07:24:39Z

@codspeedbot fix this regression

This PR didn't cause the parse_weekday regression. The benchmark gives a different result depending on the day of the week it runs.

Cause

parse_weekday calls parse_datetime("wednesday"), which resolves the weekday against the current date. When the run happens on a Wednesday, the date doesn't move. On any other day, the code adds a span of several days, which takes more work.

The main baseline (3fc6d60) ran on Wednesday 2026-10-07: 42.7 µs.
This PR's runs were on Sunday 2026-10-11: 44.7 µs. That's the reported −4.48%.
The main run before the baseline (ed95575) was also on a Sunday and measured 45 µs. That CI-only change was reported as a 5.5% "improvement" on the same benchmark.

I checked this in a CodSpeed simulation run with the same code at two fixed dates. Resolving "wednesday" from a Sunday took 21.51 µs, against 20.43 µs from a Wednesday, so about 5% slower with nothing else changed.

Fix (pushed in 000c30d)

bench_weekday now uses parse_datetime_at_date with a fixed reference date (Monday 2000-01-03, UTC). This is the same approach bench_extended_year_relative already uses. "wednesday" now always resolves two days ahead, so the result no longer depends on the day CI runs.

Because this changes what the benchmark measures, the first comparison against main on this PR will show a one-time shift for parse_weekday. You can acknowledge that shift in CodSpeed. From then on the benchmark should stay stable.

I didn't change anything else. Like the old weekday benchmark, parse_relative_time, parse_relative_time_complex and the yesterday/tomorrow/now benchmarks still use the current date, so they could show similar date-dependent noise. If you want, they can be pinned the same way in a separate PR.

Summary

Warming up the performance wizard...
Investigate parse_weekday regression — Not caused by the PR: the benchmark resolves "wednesday" relative to the date it runs on. Base ran on a Wednesday, head on a Sunday.
Make parse_weekday benchmark deterministic — Pinned to a fixed reference date (Monday 2000-01-03, UTC)
Push and reply — Pushed 000c30d
Handling comment — Comment handling finished successfully

_{Was this response helpful? React with 👍 or 👎 to help us improve CodSpeedBot.}

sylvestre · 2026-10-11T07:24:53Z

ok, let's see what is going on with the perf regression

The weekday benchmark parsed "wednesday" relative to the current date, so its cost depended on which day of the week CI ran (no date shift on a Wednesday, a multi-day shift otherwise), producing spurious regressions.

ARMeeru marked this pull request as ready for review August 31, 2026 06:53

sylvestre reviewed Sep 22, 2026

View reviewed changes

ARMeeru changed the title ~~fix(offset): correct ADT, AST, BST and GST to GNU's values~~ fix(offset): correct ADT, AST, BST, GST and SST to GNU's values Sep 22, 2026

ARMeeru requested a review from sylvestre September 22, 2026 11:21

ARMeeru force-pushed the fix/gnu-timezone-abbreviation-offsets branch from 45f04c8 to 6cccab8 Compare October 11, 2026 06:17

ARMeeru force-pushed the fix/gnu-timezone-abbreviation-offsets branch from 6cccab8 to e52fe3a Compare October 11, 2026 06:20

bench: pin parse_weekday to a fixed reference date

000c30d

The weekday benchmark parsed "wednesday" relative to the current date, so its cost depended on which day of the week CI ran (no date shift on a Wednesday, a multi-day shift otherwise), producing spurious regressions.

sylvestre merged commit 701f5a0 into uutils:main Oct 11, 2026
21 checks passed

ARMeeru deleted the fix/gnu-timezone-abbreviation-offsets branch October 11, 2026 08:12

Conversation

ARMeeru commented Aug 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

How the offsets were verified

Uh oh!

codecov Bot commented Aug 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ARMeeru Sep 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ARMeeru Sep 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

codspeed Bot commented Oct 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Merging this PR will improve performance by 3.46%

Performance Changes

Uh oh!

ARMeeru commented Oct 11, 2026

Uh oh!

sylvestre commented Oct 11, 2026

Uh oh!

codspeed Bot commented Oct 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sylvestre commented Oct 11, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ARMeeru commented Aug 31, 2026 •

edited

Loading

codecov Bot commented Aug 31, 2026 •

edited

Loading

ARMeeru Sep 22, 2026 •

edited

Loading

ARMeeru Sep 22, 2026 •

edited

Loading

codspeed Bot commented Oct 11, 2026 •

edited

Loading

codspeed Bot commented Oct 11, 2026 •

edited

Loading