Comment 3 for bug 1858883

Thanks for taking a look. Yes, it looks like the `date` utility now observes locale-based defaults, such as the new default:

$ date
Wed 25 Mar 2020 09:47:47 AM PDT

Here are some other combinations I tried:

$ LC_TIME="" date
Wed 25 Mar 2020 09:47:53 AM PDT

(setting LC_TIME to an empty string has no effect; the LC_TIME value most likely obtains a default value based on a different setting.)

The following variations produce the (formerly, at least) expected output:

$ LC_TIME="C" date
Wed Mar 25 09:47:59 PDT 2020

$ LC_ALL="C" date
Wed Mar 25 09:48:25 PDT 2020

$ LANG="C" date
Wed Mar 25 09:52:08 PDT 2020

This post suggests that LC_ALL should be set to C if the output of these utilities is meant to be read by computers:

https://unix.stackexchange.com/a/87763/4295

So while this new default does have the potential to cause regressions in users' scripts (and could be considered a regression in that sense), the fix is to correctly set LC_ALL=C in when the `date` utility is invoked in situations where its output is intended to be parsed.