Bug 682034 – sys-libs/glibc-2.29 changes output of "date" in en_US.utf8

• Product: Gentoo Linux
• Status: RESOLVED INVALID

[Description Andreas K. Hüttel 2019-03-29 22:14:58 UTC]

[20:19:47] <toralf> does by any chance glibc-2.29 has a different outout of the "date" command than 2.28 ?
[20:20:39] <dwfreed> date command is coreutils
[20:21:15] <iamben> does its format depend on locale data from glibc though?
[20:21:29] <dwfreed> it could
[20:21:48] <toralf> I do have outside of the tinderbox now : "Thu Mar 28 19:20:25 UTC 2019" and inside the chroo timages with glibc-2.29 "Thu 28 Mar 2019 07:20:34 PM UTC"
[20:22:13] <toralf> hah - idneed
[20:22:34] <toralf> b/c here's 1 tinderox image where glibc is not updated to 2.29 from 2.29 - and there it works as expected
[20:22:57] <dwfreed> what is 'locale | grep LC_TIME' ?
[20:23:30] <toralf> "locale" gives the same for host and images
[20:23:52] <toralf> http://dpaste.com/227V7ZT en_US.utf8
[20:24:23] <toralf> dilfridge: ^^ glibc-2.29 regression (indirect IMO)
[20:24:33] <dwfreed> great way to break anything that (foolishly) expects date to output a certain way
[20:25:06] <toralf> dwfreed: a quick&dirty script here at my side is broken now therefore
[20:25:33] <dwfreed> my guess is not locale data, but a change in the format string used for ctime()
[20:25:41] <dilfridge> interesting, need to track down if feature or bug
[20:26:03] <dilfridge> I guess feature, the "new" variant is somewhat more logical
[20:26:35] <dwfreed> yeah
[20:26:45] -*- toralf fixed his stumbled buggy script BTW
[20:27:15] <[Arfrever]> toralf: Use something like `date "+%Y-%m-%d-%H-%M-%S"` for parseable output.
[20:27:40] <toralf> [Arfrever]: yep, I know - but I was so lazy ...
[20:31:46] <dwfreed> dilfridge: not a change in asctime() (ctime in glibc just calls asctime(localtime(t)))
[20:31:57] <dwfreed> so it's going to be a coreutils change
[20:35:12] <toralf> dwfreed: I don't think so - the image here has the new glibc, but (just) not coreutils 8.31, still 8.30 is there - and the output differs
[20:36:15] <dwfreed> my guess is glibc 2.29 added nl_langinfo(_DATE_FMT)
[20:36:41] <dwfreed> or changed what that returned in the locale data
[20:37:01] <dwfreed> that's what date uses to find the default format string
[20:37:40] <dwfreed> if that returns empty string (or _DATE_FMT is not defined), then date uses the well-knwon default string
[20:41:32] <dwfreed> looks like _DATE_FMT has existed forever, so it's a locale data changed
[20:43:34] <dwfreed> dilfridge: https://sourceware.org/git/?p=glibc.git;a=commit;h=7395f3a0efad9fc51bb54fa383ef6524702e0c49
[20:45:21] <dwfreed> https://sourceware.org/bugzilla/show_bug.cgi?id=24046 bug link

[Comment 1 Andreas K. Hüttel 2019-03-29 22:54:41 UTC]

Answer on upstream bug: that is precisely the improvement / bugfix. so notabug.