Ignore %E and %O instead of failing to format

[aron-intframe]

POSIX gives %E and %O as modifiers that select an alternative representation (era-based years, alternative digits), and says an implementation that has no alternative representation must behave as if the modifier were absent. chrono has none, but parse_next_item has no arm for either letter, so both fall through to the error case and formatting returns Err.

That is not only a problem for a caller who types %Ey. %x, %X, %c and %r are expanded from the locale's own d_fmt, t_fmt, d_t_fmt and t_fmt_ampm while formatting, and nine of the locales in pure-rust-locales carry a modifier in those strings. So a caller who never wrote a modifier still gets an error:

thread 'repro' panicked at library/alloc/src/string.rs:2929:
a Display implementation returned an error unexpectedly: Error

On main today, rendering 2021-10-22 20:00:12+00:00:

locale	%x	%X	%c	%r
az_IR	Err	Err	Err	Err
fa_IR	Err	Err	Err	Err
lo_LA	Err	Ok	Err	Ok
lzh_TW	Err	Err	Err	Err
mnw_MM	Err	Err	Err	Err
my_MM	Err	Err	Err	Err
or_IN	Err	Err	Err	Err
shn_MM	Err	Err	Err	Err
th_TH	Err	Ok	Err	Ok

The strings behind that:

az_IR   d_fmt = %Oy/%Om/%Od       t_fmt = %OH:%OM:%OS      t_fmt_ampm = ""
fa_IR   d_fmt = %Oy/%Om/%Od       t_fmt = %OH:%OM:%OS      t_fmt_ampm = ""
lo_LA   d_fmt = %d/%m/%Ey         d_t_fmt = %a %e %b %Ey, %H:%M:%S
lzh_TW  d_fmt = %OC%Oy年%B%Od日    t_fmt_ampm = %p %OI時%OM分%OS秒
mnw_MM  d_fmt = %OC%Oy %b %Od %A  t_fmt = %OI:%OM:%OS %p
my_MM   d_fmt = %OC%Oy %b %Od %A  t_fmt = %OI:%OM:%OS %p
or_IN   d_fmt = %Od-%Om-%Oy       t_fmt = %OI:%OM:%OS %p
shn_MM  d_fmt = %OC%Oy %b %Od %A  t_fmt = %OH:%OM:%OS %p
th_TH   d_fmt = %d/%m/%Ey         d_t_fmt = %a %e %b %Ey, %H:%M:%S

fa_IR and az_IR are the awkward pair: t_fmt_ampm is empty, so %r already falls back to t_fmt, and that carries %O too.

The change

One line in parse_next_item, after the padding/alternate handling:

let spec = if spec == 'E' || spec == 'O' { next!() } else { spec };

The modifier is skipped and the base specifier is formatted. Only the era representation is lost, which chrono cannot produce anyway; the locale's own field order is kept. %E/%O at the end of a string is still an error, and %OQ is still an error, because next!() feeds an unknown specifier through the same path.

After the change every cell in the table above is Ok, e.g. th_TH %x renders 09/02/24 and fa_IR %r renders 18:54:32.

Tests

Two added:

• test_strftime_alternative_modifiers — %Ey == %y, %EY == %Y, %Od == %d, %OH:%OM:%OS renders, %%Ey stays the literal %Ey, and %E / %OQ still fail to parse.
• test_strftime_localized_alternative_modifiers — %x, %X, %c, %r parse under all nine locales, with the th_TH, lo_LA and fa_IR outputs pinned.

Both were mutation-checked rather than trusted green: removing the one-line change turns both red with the original panic.

$ cargo test --features unstable-locales
test result: ok. 301 passed; 0 failed
test result: ok. 2 passed; 0 failed
test result: ok. 1 passed; 0 failed
test result: ok. 281 passed; 0 failed

$ cargo test          # default features
test result: ok. 293 passed; 0 failed

cargo fmt --all -- --check is clean.

Context and limits

Found from the downstream side: nushell/nushell#15266, where a LC_TIME=th_TH.UTF-8 user could not start the shell because its default config formats %x %X. nushell has since worked around it locally (nushell/nushell#18918) by expanding the locale strings and stripping the modifiers before handing them to chrono, which is the same rule applied one layer out. This is the fix in the right place.

Verified on Linux, Rust stable. I did not run the MSRV, wasm, or no-std CI jobs.

🤖 Generated with Claude Code

[djc]

nushell should migrate to a different crate:

• Soft-deprecating chrono and chrono-tz #1768

[aron-intframe]

Understood on the wind-down, and that is your call to make. I am not asking you to reconsider #1768.

One correction to the framing, though: this is not a nushell problem, and it is not an unstable-locales problem either. On today's main (6adaa52), with default features and no locale feature at all, format("%Ey").to_string() panics:

thread 'repro_plain_default_features' (1465372) panicked at /rustc/8bab26f4f68e0e26f0bb7960be334d5b520ea452/library/alloc/src/string.rs:2929:14:
a Display implementation returned an error unexpectedly: Error

POSIX says an implementation that has no alternative representation must format as if the modifier were absent. parse_next_item has no arm for E or O, so they fall through to the error case, Display returns Err, and every to_string() / format!() on it panics. nushell is only where I happened to notice it.

With unstable-locales, the same gap makes chrono's own locale data unformattable for callers who never typed a modifier, because %x, %X, %c and %r are expanded from d_fmt/t_fmt/d_t_fmt while formatting. Re-run against main today:

locale   %x       %X       %c       %r
az_IR    Err      Err      Err      Err
fa_IR    Err      Err      Err      Err
lo_LA    Err      Ok       Err      Ok
th_TH    Err      Ok       Err      Ok

lzh_TW, mnw_MM, my_MM, or_IN and shn_MM are Err in all four columns too.

I had read #1768 as winding down feature work while correctness fixes still land, since git log --since=2026-01-22 shows:

2026-08-02 6adaa52 Return None from from_isoywd_opt for out-of-range years
2026-07-29 7b6436f Fix reversed `NaiveDate` day and week iterators
2026-06-18 3ffcd1b fix: clamp offset minute rounding to avoid invalid +24:00

If that reading is wrong and the door is shut on everything now, say so plainly and I will stop here. If it is right, this is a one-line panic fix in the same category as those three. The branch already sits directly on top of 6adaa52, so no rebase is needed, and it is green:

test result: ok. 301 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.14s

Both new tests are mutation-checked rather than trusted green: deleting the one changed line turns them red with the original panic.

test format::strftime::tests::test_strftime_alternative_modifiers ... FAILED
test format::strftime::tests::test_strftime_localized_alternative_modifiers ... FAILED
test result: FAILED. 299 passed; 2 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.16s

One limitation I should state rather than let you find it, because it is a genuine argument against merging: dropping the modifier loses the era value, so th_TH %x renders 09/02/24 where glibc renders the Buddhist-era year. I could not measure the glibc side to confirm the exact expected string, because th_TH.UTF-8 is not generated on this machine and date silently fell back to the C locale. So the fix trades a panic for a Gregorian year under the two era locales. That is what POSIX prescribes, but it is a real loss, and if you would rather keep the hard error than print a quietly wrong year, that is a defensible reason to leave this closed. I also did not run the MSRV, wasm or no-std CI jobs.