printf %T is severely broken, breaks compatibility

[jelmd]

Somewhere "printf %T" handling seems to got broken in a incompatible way. Discovered when upgrading to Ubuntu 24.04 which ships ksh Version AJM 93u+m/1.0.8 2024-01-01. The version shipped with the previous release, Ubuntu 22.04, seems to be ok (ksh Version AJM 93u+m/1.0.0-beta.2 2021-12-17).

E.g. the output of ksh93 -c 'LC_TIME=C printf "%(%Y-%m-%d)T\n" "now in 10 weeks"' (right now the same as ksh93 -c 'LC_TIME=C printf "%(%Y-%m-%d)T\n" "2025-11-10 in 10 weeks"'):

Expected: 2026-01-19
Got: 2025-11-10

Similar broken behavior wrt. to [abbrev.] name of the day of the week, and month of the year. E.g.:

ksh93 -c 'LC_TIME=de_DE.UTF-8 printf "%T\n" 2025-11-10'

Expected: Mo 10. Nov 00:43:42 CET 2025
Got: 10 00:44:41 MET 2025

[dnewhall]

@phidebian did the rewrite for the date support in May 2023 between those two releases, which vastly improved things, but has had some corner cases. I suspect the relevant code is in tmxdate.c, but I can't make heads or tails of it right now.

[phidebian]

Yes, tmxdate.c along with tmfix.c

Got no bandwith at the moment, can't look at it.

Just tried on Ubuntu 24.04.3 LTS

TC$ echo $KSH_VERSION
Version AJM 93u+m/1.0.8 2024-01-01

TC$ printf "%(%Y-%m-%d)T\n" "now in 10 week"                                  
2025-11-13

TC$ printf "%(%Y-%m-%d)T\n" "now in 70 day" 
2026-01-22

Seems trading 'days' for 'weeks' is straightfoward, could be a workaround.

[phidebian]

Well got some spare cycles today. This bug was introduced in commit 1a9d8ad, though touching tmxdate.c it is not related to my printf %T patch serie.

I still pushed a PR #916 in my branch named bug-182-4...

I was not the author of 1a9d8ad so may be someone should code review this PR, I think it is good, but I don't pretend understanding the big picture of this code.

At least the QA don't regress, and the new print out meet the OP request.