The --time-style=locale option to ls no longer behaves as documented.

$ locale
LANG=en_US.UTF-8
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=

$ ls --version
ls (GNU coreutils) 6.10
...

$ /bin/ls --time-style=locale -l passwd
-rw-r--r-- 1 root root 765 2007-12-07 12:42 passwd

It worked fine in version 5.97:

$ ls --version
ls (GNU coreutils) 5.97
...

$ /bin/ls --time-style=locale -l passwd
-rw-r--r-- 1 root root 765 Dec  7 17:42 passwd

It seems to me that to fix this, the formats in long_time_format need to
be set to something like
N_("oldfiletimes"),
N_("newfiletimes")
instead of
N_("%b %e  %Y"),
N_("%b %e %H:%M")
with locale_time_style (ls.c:1913) checking for those to see if the
strings are untranslated, special casing the POSIX/C locales, and then
adding en.po files to translate "oldfiles"/"newfiles" back to "%b %e
%Y"/"%b %e %H:%M". That'll also require changing all of the
translations. Otherwise, I don't see a way that the current code would
allow any locale to specify using "%b %e  %Y" or "%b %e %H:%M" as the
locale-dependent date format. (Or, I suppose that the check to see if
the time formats have been translated could be backed out.)

A patch to implement that in ls.c is fairly trivial, but I'm not sure
how to interface with the translations.

Eric Cooper <ecc@cmu.edu> wrote:
...

Thanks for the report.

Interestingly, that does work for any non-English locale.
From comparing strace output with en_US and with any non-English
locale, this appears to be because coreutils doesn't provide
any English ("en") translations (fyi, actually upstream gets its
translations from translationproject.org, and they don't
have English ones).

  $ ls /usr/share/locale/en*/LC_TIME/coreutils.mo
  zsh: no matches found: /usr/share/locale/en*/LC_TIME/coreutils.mo
  [Exit 1]
  $ ls /usr/share/locale/fr/LC_TIME/coreutils.mo
  /usr/share/locale/fr/LC_TIME/coreutils.mo@

It works fine for all other locales:

    $ LC_ALL=fr_FR /bin/ls --time-style=locale -ldgo /
    drwxr-xr-x 42 1024 mar 13 12:02 /
    $ LC_ALL=de_DE /bin/ls --time-style=locale -ldgo /
    drwxr-xr-x 42 1024 13. Mär 12:02 /

A work-around, from "info coreutils ls":

          The `LC_TIME' locale category specifies the timestamp format.
          The default POSIX locale uses timestamps like `Mar 30  2002'
          and `Mar 30 23:45'; in this locale, the following two `ls'
          invocations are equivalent:

           newline='
           '
           ls -l --time-style="+%b %e  %Y$newline%b %e %H:%M"
           ls -l --time-style="locale"

Odd.  I see that with LC_ALL=en, it *does* work:

    LC_ALL=en ./ls --time-style=locale -dl /
    drwxr-xr-x 42 root root 1024 Mar 13 12:02 /

I probably won't address this for the upcoming release, but if
someone else is interested, suggestions/patches are welcome.

Jim Meyering <jim@meyering.net> writes:

Because the en locale does not exist.

Andreas.

Hi,

This can affect invocations of `ls' that don't include an explicit
`--time-style=locale', as well, since that is now the default (in
absence of a TIME_STYLE environment variable).

The only case I can see in the head revision of `ls.c' where the
default English time-style is used is when there is no `hard locale'
in effect for time (LC_TIME=C or POSIX).

In case it might be desirable to have the time-style default to N_("%b
%e  %Y") and  N_("%b %e %H:%M") (the `defaults') rather than
'posix-long-iso' ("%Y-%m-%d %H:%M" in all cases) for locales that
begin with 'en_', I've included a small patch that provides this
behavior.

----
$ LC_ALL=zh_CN.UTF-8 src/ls -l TODO
-rw-r--r-- 1 bo bo 6908 2008-03-31 21:09 TODO

$ LC_ALL=en_US.UTF-8 src/ls -l TODO
-rw-r--r-- 1 bo bo 6908 Mar 31 21:09 TODO

$ LC_ALL=C src/ls -l TODO
-rw-r--r-- 1 bo bo 6908 Mar 31 21:09 TODO
----

Thanks,

Bo

"Bo Borgerson" <gigabo@gmail.com> wrote:

Thanks.
That feels pretty kludgy.  I hope we end up with something cleaner.

BTW, such a patch would almost certainly require doc and test changes
(a test addition, at least), as well as a NEWS entry.  If no one comes
up with something better in the next few weeks, we can revisit this.

Yeah, I suppose so.  Short of including `translations' for English,
though, what's a better option?

Okay, thanks.

Bo

What's the downside to that?

Mike Stone

Good question.  My thought was "because there aren't any now", but I
guess that's not necessarily an adequate reason.  :)

I actually don't know what the options are here, really.  Is it
possible to maintain an English translation with only LC_TIME info?

Bo

How about just treating "no translations available" as equivalent to LANG=C ?
Superficially, it's less Anglo-centric :-)

Quite the opposite, which is the problem. LANG=C specifies a particular,
somewhat unusual US-English date representation. Therefore (as I
mentioned in a previous email) LANG=C has to be special cased, and
probably shouldn't be treated as identical to "no translation".

Mike Stone

"Bo Borgerson" <gigabo@gmail.com> writes:

Yes.  I maintain an English translation by hand for GNU diffutils.
This is for LC_MESSAGES but a similar thing could be done for LC_TIME.

The diffutils message translations are to display appropriate symbols
for copyright ("©" rather than "(C)") and for authors' names (Torbjörn
Granlund).  Also, it rewrites "illegal" to "unrecognized" in a context
where POSIX requires the word "illegal" even though the GNU project
prefers to reserve "illegal" for things that are actually illegal.
Perhaps coreutils could do something similar there, too, after the
next stable release goes out.

Paul Eggert <eggert@CS.UCLA.EDU> wrote:

If you mean the getopt diagnostic, it is no longer required.
FYI, upstream glibc changed its diagnostic recently.