bug(date) incorrectly converts `%Y` to the Thai Buddhist calendar when `LC_TIME=th_TH.UTF-8` is set.

[compilersutra]

Reproducer

$ locale -k LC_TIME
abday="Sun;Mon;Tue;Wed;Thu;Fri;Sat"
day="Sunday;Monday;Tuesday;Wednesday;Thursday;Friday;Saturday"
abmon="Jan;Feb;Mar;Apr;May;Jun;Jul;Aug;Sep;Oct;Nov;Dec"
mon="January;February;March;April;May;June;July;August;September;October;November;December"
era=
alt_digits=

env -u LC_ALL LC_TIME=th_TH.UTF-8 \
./target/release/date -d "2026-06-14" "+%Y %B %A"

Actual output

2569 มิถุนายน วันอาทิตย์

Expected output

2026 June Sunday

GNU comparison

env -u LC_ALL LC_TIME=th_TH.UTF-8 \
date -d "2026-06-14" "+%Y %B %A"

GNU date prints:

2026 June Sunday

Notes

The active LC_TIME data contains:

mon="January;February;March;April;May;June;July;August;September;October;November;December"
day="Sunday;Monday;Tuesday;Wednesday;Thursday;Friday;Saturday"
era=
alt_digits=

However, uutils prints a Buddhist Era year (2569) and Thai month/weekday names.

This suggests that the formatter is not honoring the active locale data and is instead deriving formatting behavior directly from the locale identifier (th_TH.UTF-8).

Expected behavior is to match GNU date and use the values provided by the active LC_TIME definition.

[HackingRepo]

no that pr wrong @sylvestre, i;m using an oudtated a bit gnu version, i closed the issue, close it too

[compilersutra]

I'm testing against GNU coreutils 9.4:

$ date --version
date (GNU coreutils) 9.4

which is relatively recent and not particularly old.

With this version, GNU date produces:

env -u LC_ALL LC_TIME=th_TH.UTF-8  date -d "2026-06-14" "+%Y %B %A"

Output:

2026 June Sunday

Could you share the GNU coreutils version and locale setup you tested with? I'd like to reproduce the behavior you're seeing before closing the issue.

[HackingRepo]

my gnu version @compilersutra even not old than yours look

relunsec@relunsec:~/Desktop$ gnudate --version
date (GNU coreutils) 9.7
Packaged by Ubuntu (9.7-3ubuntu2)
Copyright (C) 2025 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.
relunsec@relunsec:~/Desktop$ 

but not very latest since 9.11 you used 9.4, whiches even older than 9.7

[compilersutra]

Thanks for sharing your version.

To avoid any confusion from distro patches or version differences, I’m cloning and building the latest GNU coreutils directly from upstream now, then I’ll re-run the exact same reproducer against that build.

I’ll compare:

env -u LC_ALL LC_TIME=th_TH.UTF-8 date -d "2026-06-14" "+%Y %B %A"

I m using the repo

git.savannah.gnu.org/git/gnulib.git

with the current uutils output and report the result here.

[compilersutra]

I verified this against a current GNU coreutils build at /home/aitr/rust_bugs/gnucoreutils/src/date:

> /home/aitr/rust_bugs/gnucoreutils/src/date --version

date (GNU coreutils) 9.11.100-16d29
Copyright (C) 2026 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

With the latest GNU build, the repro still differs from uutils:

  env -u LC_ALL LC_TIME=th_TH.UTF-8 ./target/release/date -d "2026-06-14" "+%Y %B %A"
  2569 มิถุนายน วันอาทิตย์

env -u LC_ALL LC_TIME=th_TH.UTF-8 /home/aitr/rust_bugs/gnucoreutils/src/date -d "2026-06-14" "+%Y %B %A"
 2026 June Sunday

[sylvestre]

yeah, it is a bug on our side. %Y should return 2026
%EY should return 2569

[compilersutra]

shall i work on it and provide a patch?

[sylvestre]

sure, thanks