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 <[email protected]> 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 <[email protected]> wrote: >>> On Wed, Jul 29, 2015 at 9:27 AM, Rob Landley <[email protected]> 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 <[email protected]> >>>>> 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 >>>> [email protected] >>>> 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. > > > _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
