Repository navigation
date: strftime flags propagate into composite specifiers (%-D, %-F, …) #11657
Description
Summary
GNU date treats composite strftime specifiers (%D, %F, %T, %r, %R, %c, %x, %X) as atomic: flags like - apply to the whole expansion, not to inner sub-fields. uutils lets the - flag propagate into the inner %m, producing 6/15/24 instead of 06/15/24.
Found by a fuzz_date run.
Reproduction
$ LC_ALL=C TZ=UTC /usr/bin/date -d '2024-06-15' '+%-D'
06/15/24
$ LC_ALL=C TZ=UTC target/debug/coreutils date -d '2024-06-15' '+%-D'
6/15/24Test
#[test]
fn test_date_strftime_flag_on_composite() {
new_ucmd!()
.env("LC_ALL", "C")
.env("TZ", "UTC")
.arg("-d")
.arg("2024-06-15")
.arg("+%-D")
.succeeds()
.stdout_is("06/15/24\n");
}
Activity
THEMIScale commentedon Apr 10, 2026
I'll try to work on it.
Abusalah0 commentedon Apr 10, 2026
Hey @THEMIScale , can I try to do this one if you have not started working on it yet?
THEMIScale commentedon Apr 10, 2026
@Abusalah0 sure, go ahead.
Abusalah0 commentedon Apr 10, 2026
Thanks @THEMIScale .
I can reproduce this on
mainas described by @sylvestre :datewithLC_ALL=C TZ=UTCand+%-Doutputs:06/15/246/15/24This appears to stem from how composite
strftimedirectives are handled during modifier processing. GNU treats composite specifiers as atomic, applying modifiers to the fully rendered result, while uutils currently allows modifier logic to propagate into inner sub-fields.I’ve prepared a fix that treats composite directives (
%D,%F,%T,%r,%R,%c,%x,%X) as atomic for modifier handling, while preserving top-level width and padding behavior.Additionally:
%+10Dparity testI’ll open a PR shortly for review.
date: skip '-' flag for composite strftime specifiers
date: skip '-' flag for composite strftime specifiers
date: skip '-' flag for composite strftime specifiers
date: drop pad flags before composite strftime specifiers
date: drop pad flags before composite strftime specifiers
SichenLiang commentedon Sep 2, 2026
Upstream fixed this on Monday, and the result isn't quite "composites are
atomic" — there's one exception.
Pádraig took it to bug-gnulib after #339 on the coreutils mirror, and the fix
went in as gnulib 91c129e9dbd8 on Aug 31:
Coreutils bumped the submodule the same day (15b8d8ab8287). So
date -d 2005-03-04 +%-D, which gives03/04/5on 9.7 and 9.11, becomes03/04/05inthe next release — but
%Fkeeps propagating:Worth having on the radar for the PRs here: handling every composite the same
way matches GNU for
%D %T %R %r %x %X, but%Fgoes the other way.One thing that may save someone time: #339's tests landed as 85857f1eaa70 with
the year moved from 2024 to 2004 — "that better tests the padding propagation to
%y" (Pádraig, on the mirror PR). The
#[ignore]d composite test intests/by-util/test_date.rs is on 2024-06-15, where
%yis24— nothing tostrip, so it passes under either behaviour. The new coreutils date.pl has dates
and cases that do discriminate.
Measured on b7519db against GNU 9.7 (Ubuntu 26.04) and the 9.11 reference
build,
TZ=UTC LC_ALL=C.xtqqczze commentedon Oct 13, 2026
Confirmed that the issue is resolved by #15111.
The following comparison demonstrates the behavior before and after the fix: