bug#11843: acknowledged by developer (date -s with locale-dependent input: notabug)

[Jim Meyering]

peter evans wrote:
> Thank you for closing this as "not a bug".
>
> So it is not a bug that date is unable to parse its own output in
> arbitrary locales.
> Indeed, it would "not be a bug" if it stopped and complained about
> it. That would be
> perfectly acceptable.
>
> "date" however, goes one better than that, rather than alerting you to
> the fact that
> you have tried something stupid, like having a locale other than "C",
> it will just set
> the date to whatever it feels like.
>
> At the very least, it should stop and complain rather than setting
> some random time.
> This is a bug. The rest of the world does not live in some undefined subset of
> "locales that date groks."

I agree.  The lack of diagnostic is indeed a bug.
I'll remove the "notabug" tag.
Thanks for persevering.

This demonstrates the bad behavior:

    $ date -d "$(printf '\xb0')"
    Wed Jul  4 00:00:00 CEST 2012

With the patch below, it now diagnoses the problem:

    $ src/date -d "$(printf '\xb0')"
    src/date: invalid date '\260'
    [Exit 1]

I'll add tests and NEWS.


diff --git a/lib/parse-datetime.y b/lib/parse-datetime.y
index 67669f6..4d9f65a 100644
--- a/lib/parse-datetime.y
+++ b/lib/parse-datetime.y
@@ -113,6 +113,11 @@ typedef long int long_time_t;
 typedef time_t long_time_t;
 #endif

+/* Convert a possibly-signed character to an unsigned character.  This is
+   a bit safer than casting to unsigned char, since it catches some type
+   errors that the cast doesn't.  */
+static inline unsigned char to_uchar (char ch) { return ch; }
+
 /* Lots of this code assumes time_t and time_t-like values fit into
    long_time_t.  */
 verify (TYPE_MINIMUM (long_time_t) <= TYPE_MINIMUM (time_t)
@@ -1171,7 +1176,8 @@ yylex (YYSTYPE *lvalp, parser_control *pc)
         }

       if (c != '(')
-        return *pc->input++;
+        return to_uchar (*pc->input++);
+
       count = 0;
       do
         {