Re: LC_TIME: date_fmt vs d_t_fmt

[PÃdraig Brady <P at draigBrady dot com>]

On 10/04/16 06:40, Mike Frysinger wrote:
> the `date` command will default to the LC_TIME.date_fmt field.  it does
> this by looking up nl_langinfo(_DATE_FMT) (iff _DATE_FMT is defined).
> if that isn't available, it falls back to the default:
> 	%a %b %e %H:%M:%S %Z %Y
> this is required by POSIX for the POSIX locale, but works generally too.
> 	http://pubs.opengroup.org/onlinepubs/9699919799/utilities/date.html#tag_20_30_10
>
> the GNU coreutils date code lives here (as does all this logic):
> 	http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/date.c
>
> the LC_TIME.date_fmt was first added to glibc here:
> 	https://sourceware.org/ml/libc-alpha/2000-10/msg00298.html
> 	https://sourceware.org/git/?p=glibc.git;a=commit;h=d8337213c83c3bd4aa32e16669745dd7ee32b329
>
> it quoted the XPG4 standard for the background.  i haven't been able to
> locate that old standard, but all the ones i do have access to (SuSv2
> and newer) do not mention _date_fmt or date_fmt anywhere that i can find.
>
> we get a steady stream of complaints (some in our bugzilla, but via other
> sources as well like the mailing list or distro users) that the output of
> `date` does not match their expectations.  in the end, they end up saying
> that want something that looks very much like `date +%c` which is what the
> LC_TIME.d_t_fmt field is set to.
>
> so what should we do here ?  we provide 0 guidance to locale writers which
> means we get inconsistent behavior across locales.  options:
> (1) punt date_fmt entirely (so `date` uses the POSIX default everywhere)
> (2) change date_fmt internally to always return %c
> (3) try to clearly define the difference between date_fmt and d_t_fmt --
>      anyone know what that is ?  or have access to the XPG4 definition ?
> (4) somethine else ?
> -mike

I have to agree that this is strange/confusing.
I see date_fmt is _not_ mentioned in the POSIX LC_TIME items:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html#tag_07_03_05

Guessing I would say that the POSIX default "+%a %b %e %H:%M:%S %Z %Y" format,
while being in an awkward order is to be backwards compat with some
historical implementation of date(1), and that date_fmt was a way
to configure this particular format? I.E. it might more accurately be
called date_command_fmt? Not that I agree that command specific config
should be in the locale db at all.

As for the default output from date(1).
Doing (1), wouldn't change anything for 284 out of 318 locales on Linux at least.

A summary of the other 34 locales' formats is:
  $ locale -a | sed 's/[.@].*//' | uniq | while read l; do
     date_fmt=$(LC_TIME=$l locale date_fmt)
     [ "$date_fmt" != '%a %b %e %H:%M:%S %Z %Y' ] && echo $l
    done |
    while read l; do
      test "$(LC_TIME=$l locale date_fmt)" != "$(LC_TIME=$l locale d_t_fmt)" && echo $l
    done |
    while read l; do
      echo ====$l====; LC_TIME=$l locale date_fmt d_t_fmt
    done

You might go a bit farther and have date(1) default to d_t_fmt
when not in the C locale (note the C locale d_t_fmt doesn't contain %Z).
That would in effect apply what those 34 locales were trying to do
(give better output from date(1)) to all locales.

thanks,
PÃdraig.