[Toybox] date test failures

[enh]

On Fri, Apr 29, 2016 at 6:34 PM, Rob Landley <rob at landley.net> wrote:
> On 03/19/2016 02:44 AM, Andy Chu wrote:
>> On the master branch, I'm getting these failures.  The difference is
>> "Wed" vs "Sat" in the error message.
>
> So this is still there, but the tests are nonsense:
>
>> # Accidentally given a Unix time, we should trivially reject that.
>> testing "Unix time missing @" "TZ=UTC date 1438053157 2>&1" \
>>   "date: bad date '1438053157'; Wed February 38 05:31:00 UTC 2057 != Sun Mar 10 05:31:00 UTC 2058\n" "" ""
>> # But some invalid dates are more subtle, like Febuary 29th in a non-leap year.
>> testing "Feb 29th" "TZ=UTC date 022900001975 2>&1" \
>>   "date: bad date '022900001975'; Wed Feb 29 00:00:00 UTC 1975 != Sat Mar  1 00:00:00 UTC 1975\n" "" ""
>
> This is why I don't usually check for specific error messages. For one
> thing, none of our date tests work with TEST_HOST. At least SOME of our
> tests should, the rest should be marked as such, ala:
>
>   SKIP_HOST=1 testing "test test test"
>
> Here we're checking for too-specific error messages and failing because
> various libcs don't agree what day of the week an impossible date would
> fall on. The 5th of snozberries is a tuesday, not a thursday. Right.
>
>> I don't really understand what it's trying to tell me though... FYI
>> GNU coreutils gives:
>>
>> $ date 1438053157
>> date: invalid date ‘1438053157’
>
> Would be fine. Ours would be "date: bad date '1438053157'"

it wasn't fine in real life though... this caused much confusion in
Android QA. what they needed to be told was "this argument should be
of the form YYYYMMDDHHmm, not a Unix epoch time". but, yes, an error
that just included the format we were *trying* to parse would be
sufficient (and probably better, since this error clearly failed in
communicating its purpose to you two).

> And it looks like our error checking logic can be simplified? (Just
> mktime, localtime_r, and then strftime it back and do a sting compare.
> We've already got that code for the error reporting case, it might be
> slightly slower but it's not going to be bigger.)
>
> And while we're at it, bracket if (flag) setenv() and if (flag) clearenv
> around the caller lets us collapse to only one caller so we can inline it...
>
> Rob
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net



-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.