coreutils date: localized output keeps C locale order

[ednl (Ewoud Dronkert)]

Concerning: macOS 10.14.2, MacPorts 2.5.4, coreutils 8.30, GNU date (gdate). I use the nl_NL.UTF-8 locale on my Mac:

$ locale
LANG="nl_NL.UTF-8"
LC_COLLATE="nl_NL.UTF-8"
LC_CTYPE="nl_NL.UTF-8"
LC_MESSAGES="nl_NL.UTF-8"
LC_MONETARY="nl_NL.UTF-8"
LC_NUMERIC="nl_NL.UTF-8"
LC_TIME="nl_NL.UTF-8"
LC_ALL=

The localized output of `gdate' does translate the day and month names (but not the timezone, which is expected maybe) but keeps the C-locale order:

$ LC_ALL=C /opt/local/bin/gdate
Sat Dec  8 11:32:02 CET 2018
$ LC_ALL=nl_NL.UTF-8 /opt/local/bin/gdate
za dec  8 11:32:24 CET 2018

That order is the same for any other locale. However, the order for my locale should be "%a %e %b %Y %X %Z" as found in the macOS locale definition:

$ /bin/date
za  8 dec 2018 11:54:44 CET
$ cat /usr/share/locale/nl_NL.ISO8859-1/LC_TIME | grep %Z
%a %e %b %Y %X %Z

(There is no separate UTF-8 definition for LC_TIME.) Or on my Debian system, which is (effectively) the same:

$ cat /usr/share/i18n/locales/nl_NL | grep -A2 date_fmt
date_fmt       "<U0025><U0061><U0020><U0025><U0065><U0020><U0025><U0062>/
<U0020><U0025><U0059><U0020><U0025><U006B><U003A><U0025><U004D><U003A>/
<U0025><U0053><U0020><U0025><U005A>"

There is no /opt/local/share/i18n/ directory on my MacPorts installation. Is that the problem? Or should the definitions from /usr/share/locale/ be used? It definitely seems wrong that the names are localized but the order isn't.

[ryandesign (Ryan Carsten Schmidt)]

Hmm, well MacPorts is probably not doing anything special to build coreutils, so if this problem exists, then it exists in the coreutils code, and you should report it to the developers of coreutils.

[jmroot (Joshua Root)]

Where did /opt/local/bin/date come from? The coreutils port only seems to provide /opt/local/bin/gdate and /opt/local/libexec/gnubin/date.

[ednl (Ewoud Dronkert)]

Replying to jmroot:

Where did /opt/local/bin/date come from? The coreutils port only seems to provide /opt/local/bin/gdate and /opt/local/libexec/gnubin/date.

Oh, sorry! That was my own symlink addition. Yes, it provides gdate and I simply made a link to supersede the system (BSD) date, which works because /opt/local/bin occurs earlier than /bin in my PATH.

[ednl (Ewoud Dronkert)]

Replying to ryandesign:

Hmm, well MacPorts is probably not doing anything special to build coreutils, so if this problem exists, then it exists in the coreutils code, and you should report it to the developers of coreutils.

No, I don't think it is a coreutils problem, because the correctly localized order of the date fields does get picked up by GNU date on Debian. The problem here on macOS is that there doesn't seem to be correct integration with the macOS locale, perhaps because the i18n directory is not present. Could be a hardcoded path? But that is just speculation on my part. What I describe in the ticket is not correct behaviour, and the problem doesn't occur on Linux.

[ednl (Ewoud Dronkert)]

This is still faulty.