Re: date ignores locale when parsing short dates

[Bob Proulx]

Adam Nielsen wrote:
> I've encountered a small issue with the way the date utility parses
> textual dates.  It seems to ignore the locale settings and assume US
> date formats, and I'm not sure how to get it to respect the local date
> format.
>
>   # Incorrect, locale says short dates are dd-mm-yy
>   $ LC_TIME="en_AU" date +%Y-%m-%d -d 1/2/03
>   2003-01-02
>   # Should be 2003-02-01

I don't think it is possible with the current code.  I see in the
documentation for date this text.  I didn't check the code but the
docs seem to be explicit.

  ‘-d DATESTR’
  ‘--date=DATESTR’
     Display the date and time specified in DATESTR instead of the
     current date and time.  DATESTR can be in almost any common format.
     It can contain month names, time zones, ‘am’ and ‘pm’, ‘yesterday’,
     etc.  For example, ‘--date="2004-02-27 14:19:13.489392193 +0530"’
     specifies the instant of time that is 489,392,193 nanoseconds after
     February 27, 2004 at 2:19:13 PM in a time zone that is 5 hours and
     30 minutes east of UTC.

And here is the part to note.

     Note: input currently must be in locale independent format.  E.g.,
     the LC_TIME=C below is needed to print back the correct date in
     many locales:
          date -d "$(LC_TIME=C date)"
     *Note Date input formats::.

Sorry but I think that documents that input formats must be in the C /
POSIX locale if the value is ambiguous.

> Am I doing something wrong?  I've read that -d uses the "POSIX locale"
> rather than the user locale -

Yes.  As noted in the docs.

> if so, is there a way to get date's fancy processing with mm/dd
> swapped to dd/mm, without resorting to regexes?

I can read the above ambiguously two different ways.  One way is that
sorry no it isn't possible.  The other way is that date itself can
produce the output in the C locale suitable for input to date as shown
in the documentation example.  Which way did you mean it?

On the other hand if you use text months with dashes then the parser
seems to sort it out okay.

  LC_TIME="en_AU" date +%Y-%m-%d -d 1-feb-03
    2003-02-01

Obviously unambiguous date formats are the best.  I tend to like using
date format "+%F %T %z" (2003-01-02 00:00:00 -0700) for example.  And
of course working in UTC is always best too.

Bob