date input: trailing TZ abbreviation (e.g. `2024-01-01 EST`) keeps input TZ on output instead of re-zoning

[sylvestre]

Summary

When -d is given a date string with a trailing timezone abbreviation (e.g. 2024-01-01 EST), GNU date parses the instant and then displays it in the local TZ. uutils parses it correctly but keeps the result in the input's timezone for display, producing the wrong wall-clock time.

Found by a fuzz_date run on uutils/coreutils.

Reproduction

$ TZ=UTC+1 /usr/bin/date -d '2024-01-01 EST'
Mon Jan  1 04:00:00 UTC 2024

$ TZ=UTC+1 target/debug/coreutils date -d '2024-01-01 EST'
Mon Jan  1 00:00:00 -05 2024

$ TZ=UTC+1 /usr/bin/date -d '2024-01-01 EST' '+%H:%M:%S %:z'
04:00:00 -01:00

$ TZ=UTC+1 target/debug/coreutils date -d '2024-01-01 EST' '+%H:%M:%S %:z'
00:00:00 -05:00

Both parsed the instant correctly; the divergence is in how the resulting Zoned is re-projected into the local timezone before display.

Test (in uutils/coreutils integration suite)

#[test]
fn test_date_input_trailing_tz_abbrev_rezones() {
    new_ucmd!()
        .env("LC_ALL", "C")
        .env("TZ", "UTC+1")
        .arg("-d")
        .arg("2024-01-01 EST")
        .arg("+%H:%M:%S %:z")
        .succeeds()
        .stdout_is("04:00:00 -01:00\n");
}