[Toybox] [PATCH] Reject invalid dates in date(1).

[Rob Landley]

Applied, and then more changes applied on top of that. Passed basic
testing but it's entirely possible I broke it, but I'm a little annoyed
and need to step away from the keyboard a bit.

(In 2015 we should be able to pass a directory filehandle to file
manipulation APIs, and the time stuff should have a nanoseconds field.
Not just some of it, all of it. Neither posix nor glibc have been
particularly helpful in this regard. I have been reminded that the
gnu/dammit date command implements %N but doesn't put it in strptime,
which means they thought rewriting strptime longhand inside their date
implementation was a logical thing to do.)

Rob

On 08/07/2015 05:09 PM, enh wrote:
> ping. i'm still getting hassled about this. want me to send a more
> BSD-like patch that just rejects clearly invalid dates? or to actually
> add the leap year logic (so we reject all invalid dates, but still
> allow "non canonical" times)? i'm happy to write whichever, if you
> tell me which you want. (and even the least-strict BSD solution would
> be enough to make my users happy.)
> 
> On Wed, Jul 29, 2015 at 10:04 AM, enh <enh at google.com> wrote:
>> (and i didn't experiment to work out how strict coreutils is, other
>> than that -- unlike two of the three BSDs -- it isn't fooled by
>> feburary 29th in non-leap years.)
>>
>> On Wed, Jul 29, 2015 at 10:03 AM, enh <enh at google.com> wrote:
>>> On Wed, Jul 29, 2015 at 9:27 AM, Rob Landley <rob at landley.net> wrote:
>>>> On 07/28/2015 03:38 PM, enh wrote:
>>>>> (i haven't actually merged this in the Android tree, but my git-fu is
>>>>> too weak to get a diff of a new file otherwise.)
>>>>>
>>>>> Author: Elliott Hughes <enh at google.com>
>>>>> Date:   Tue Jul 28 13:14:17 2015 -0700
>>>>>
>>>>>     Reject invalid dates in date(1).
>>>>>
>>>>>     Humans get upset when date(1) lets mktime(3) work out what the 99th day
>>>>>     of the 99th month would be rather than rejecting the invalid date. For
>>>>>     the subtly wrong cases, rather than get into the leap year business,
>>>>>     let's rely on localtime_r(3).
>>>>>
>>>>>     Bug: http://b/22788816
>>>>
>>>> I don't suppose there's a better bug URL than that?
>>>
>>> no, it was an internal bug. apparently CTS was assuming it could pass
>>> a Unix epoch time, but instead of rejecting it we were setting the
>>> clock to a crazy time way in the future leading to obscure unexpected
>>> test behavior.
>>>
>>>> I note that people do actually use this behavior:
>>>>
>>>> http://lists.busybox.net/pipermail/busybox/2005-June/048753.html
>>>
>>> my original version of this patch just checked that the various fields
>>> were in range, but when i got to checking tm_mday and needed to deal
>>> with leap years i decided to let localtime_r take the strain instead.
>>> we can go back to that if you like. either solves my problem.
>>>
>>>> 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.
>>
>>
>>
>> --
>> Elliott Hughes - http://who/enh - http://jessies.org/~enh/
>> Android native code/tools questions? Mail me/drop by/add me as a reviewer.
> 
> 
> 

 1439069502.0