Merging this PR will degrade performance by 6.25%

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

❌ 3 regressed benchmarks
✅ 18 untouched benchmarks

Performance Changes

Comparing 0xSoftBoi:fix/ignore-trailing-noise-tokens (7d069b4) with main (4b412e0)

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.31%. Comparing base (4b412e0) to head (7d069b4).
⚠️ Report is 8 commits behind head on main.

@@           Coverage Diff           @@
##             main     #286   +/-   ##
=======================================
  Coverage   99.30%   99.31%           
=======================================
  Files          20       21    +1     
  Lines        3894     3942   +48     
  Branches      122      123    +1     
=======================================
+ Hits         3867     3915   +48     
  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.
📢 Have feedback on the report? Share it here.

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

please run cargo fmt

Review bump on this PR. I see the current blockers are the formatting failure and the CodSpeed regression flag; I can follow up on the formatting immediately, but I’d still appreciate a maintainer read on whether the GNU-compat behavior for trailing noise-after-pure-number is acceptable before this drifts.

Pushed 06267b3 to address the CodSpeed regression. Instead of making Item::Noise a global alt branch, noise consumption is now folded into parse_item and only fires after a Pure item, gated on a cheap peek that confirms the next token is not a real item (timezone/offset/etc., e.g. BRT in 8 BRT).

That keeps the hot invalid-input and weekday paths byte-identical to main (no extra alt branch), so the previous -13.27% flag on parse_invalid_input should clear. All 377 tests still pass and the original noise_after_pure_number cases (8j, 8 j, 1230foo, plus the negative cases) are unchanged. cc @sylvestre

I don't think this is the right fix — GNU accepts 8j because j is a military timezone letter (local time), not because it discards unrecognized tokens. You can see this because GNU also accepts 8 z→08:00, 8 k→22:00, 8 brt→11:00 (all timezones), but rejects 8foo, 1230foo, 8 pizza, 8xyz. The generic noise-swallowing here makes all of those invalid inputs parse successfully, diverging from GNU and (when wired into coreutils) breaking its existing --set 123abcd invalid-date test. The correct scope for #279 is much narrower: add j to the named-timezone table (it already resolves z/k/brt), rather than consuming arbitrary trailing alpha after a pure number.

Closing this in favour of #320, which does the same job on a correct premise.

@sylvestre — your review was right, and it is worth recording exactly how. This PR assumed GNU silently ignores unrecognized trailing alphabetic tokens after a pure number. It does not:

$ date -d '8foo'
date: invalid date ‘8foo’

So the "ignore the noise" model was wrong. I checked the whole alphabet against GNU coreutils 9.4, and the real rule is narrower: every letter a–y is a military time zone, and all of them were already in our table except j. That one letter was the entire gap.

j was missing because it is the only letter that is not a fixed offset — it means local time:

$ TZ=America/New_York date -d '8j'            # 08:00 -0400   (same as bare '8')
$ TZ=America/New_York date -d '2026-01-01 j'  # 00:00 -0500   (DST-aware)
$ TZ=America/New_York date -d '8z'            # 04:00 -0400   (z is UTC)

So it cannot be represented as an Offset at all, which is presumably why it was skipped originally.

#320 adds it as a proper time zone item — so 8j utc and 8 j j are still rejected as a repeated zone, and 8foo still errors. All 26 letters now match GNU exactly.

This branch is also five months behind main and its diff would revert several later fixes, including my own am/pm change, so #320 is a fresh branch from current main rather than an update here.