Significant increase of the ls & date binary size when built independantly

[sylvestre]

See:
https://github.com/uutils/coreutils-tracking/blob/main/individual-size-results/ls.png

@cakebaker identified that it has been caused by #7194

[GTimothy]

From investigating, it seems the issues stems from the tz_str.parse() call

coreutils/src/uucore/src/lib/features/custom_tz_fmt.rs

Line 18 in a64fce8

Ok(tz_str) => tz_str.parse().unwrap(),

which may be bringing a large amount of code from here https://docs.rs/chrono-tz/latest/src/chrono_tz/opt/rustwide/target/x86_64-unknown-linux-gnu/debug/build/chrono-tz-a2dcc687cb5874ae/out/timezones.rs.html#2672 (yes, the file is 77115 lines long)

[drinkcat]

I think we should use tzfile where available (i.e. on most Unixes?): https://crates.io/crates/tzfile

Temporary branch is here: https://github.com/drinkcat/coreutils/tree/timezone-use-system, stacks on top of #7597. (@jadijadi FYI):

$ cat startsize.7504 # Original size
-rwxr-xr-x 2 drinkcat drinkcat 4826544 Apr  5 11:03 target/release/date
-rwxr-xr-x 2 drinkcat drinkcat 3767944 Apr  5 11:02 target/release/ls
$ ls -l target/release/{date,ls}
-rwxr-xr-x 2 drinkcat drinkcat 2939344 Apr  5 12:29 target/release/date
-rwxr-xr-x 2 drinkcat drinkcat 1897424 Apr  5 12:29 target/release/ls

(this doesn't work on Windows, as expected: https://github.com/drinkcat/coreutils/actions/runs/14281053589)

It seems really odd now to not just use chrono's %Z formatting now (since we extract the abbreviation from that...), not sure why we have this workaround, and how that plays with chrono-tz. This was merged in #7134 but I think the original code is much older.

I'll keep digging.