date utility format unexpectedly changed after upgrade from bionic to focal

[Mike Pontillo]

After upgrading my Bionic system to Focal, I noticed a significant change in the output of the `date` utility. This could potentially cause regressions for those who are relying on a consistent date format when using `date` in shell scripts.

EXPECTED BEHAVIOR
=================

I expected to see the same date format that can be seen on Ubuntu releases (at least) from Trusty through Bionic:

$ date -u
Wed Jan 8 21:00:14 UTC 2020

ACTUAL BEHAVIOR
===============

On Focal (and Eoan) the following date format is seen by default:

$ date -u
Wed 08 Jan 2020 09:00:14 PM UTC

Note the differences in zero-padding, whitespace, placement of the year, and the extraneous "PM" (I had expected to see a 24-hour time).

FURTHER DETAILS
===============

This machine was originally on Bionic and has been upgraded to development releases between Bionic and Focal.

$ locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

[Andreas Hasenack (ahasenack)]

Locales are complicated and not my cup of tea ;)

Found this: https://superuser.com/questions/1497422/debian-9-vs-debian-10-different-date-output-the-same-locale-the-same-timezone

Another user noted the same change when going from debian 9 to debian 10. I honestly don't know if this is a bug, or if it's fixing a bug.

Since LC_TIME is set to en_US, maybe the new output in focal is fixing a bug, and using the US format?

[Mike Pontillo (mpontillo)]

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.

[Andreas Hasenack (ahasenack)]

I tend to agree, not only for date parsing, but plain "language" parsing, it's best to force LC_ALL=C before running whatever tool you want to inspect the output of. I can add a release notes task to this and update them.