[Toybox] [PATCH] Fix year parsing in date(1).

[enh]

On Fri, Nov 13, 2015 at 7:08 AM, Rob Landley <rob at landley.net> wrote:
> On 11/12/2015 10:32 PM, enh wrote:
>> thanks. that's got people off my back.
>
> Sorry for the delay.

not your fault. they didn't make it clear to me that this was urgent
until they were all a-panic.

(it's also not like this was a recent regression, so they really
should have noticed this months ago. but anyway...)

>> i did notice while testing 4-digit years (which is what the bug report
>> was about) that 2-digit years don't work as you intended them to
>> either. (the behavior didn't seem entirely unreasonable to me, because
>> what kind of person uses two digit years anyway?)
>
> Properly testing date is another thing queued up on the qemu-based root
> testing infrastructure. (Because after I set the date on my work machine
> a century into the future once and my desktop got _really_unhappy_ in a
> way not trivially fixed, I may have gotten a bit gun-shy...)

the existing tests use -d to let us parse dates and print what we
think we saw without actually messing with the system clock.

>> anyway, three missing test cases:
>> 1. if a 0-digit year is supplied, the year should be the current year.
>> right now it's 1900.
>> 2. the 2-digit year 75 should be "1975".
>> 3. the 2-digit year 16 should be "2016".
>>
>> these all boil down to this comment being wrong:
>>
>>   // If year specified, overwrite one we fetched earlier
>>
>> maybe at some point you had fetched a year earlier, but currently at
>> this point, tm_year is 0. (because the last thing that happened to the
>> struct tm was that it was memset to 0.)
>>
>> i started to write a patch, but realized i'd rather just disallow
>> 2-digit years.
>
> Alas, I've encountered them in the wild. (Don't currently remember where
> though.)
>
>> i'm assuming that -- even though POSIX's explicit
>> specification of which years are past and which are future is a bit
>> crazy -- you don't want to deviate from POSIX so far that you just
>> reject 2-digit years?
>
> The deviation from Posix I documented (end of the comments at the top)
> was 50 years in the past/future.
>
> I should really engage more on the posix mailing list and maybe get
> _them_ to change their hardwired constant range here, but Jorg "linux
> sux cdrecord rulez" Schilling being one of the consistently louder
> voices there makes me go "maybe writing/maintaining my own spec would be
> easier" and that puts it down into the "if I retired and did open source
> fulltime maybe I'd have time to put into that" area of my todo list. (I
> wonder if Michael Kerrisk or Jonathan Corbet has spare time and no sense
> of self preservation? The answer is almost certainly "no", but...)
>
>> (though that might be a less problematic
>> incompatibility than having a different interpretation of
>> past/future?)
>
> Parsing 2-digit years is problematic in that it's not constant behavior
> but instead releative to the current time... but it would also be
> problematic for it to be constant behavior because as the new king of
> canada reminds us, "it's 2015" and the date range in 2013's
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/date.html is
> the same date range in 2001's
> http://pubs.opengroup.org/onlinepubs/7908799/xcu/date.html despite a
> dozen years passing between the two. (At this point we're only a few
> years off from "50 years into the past/future" matching the posix
> behavior anyway. :)

fwiw Java's date parsing uses -80/+20. (but they also let you override
it if you want to.)

> If you think declaring 2-digit date setting (without an explicit
> pattern) broken is a better fix than making it track the current date, I
> haven't got a major objection, but personally I'd rather try to fix it...

since i'd never dream of using a 2-digit year i don't have a strong opinion.

> Rob



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

 1447457511.0