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

[Rob Landley]

On 11/12/2015 10:32 PM, enh wrote:
> thanks. that's got people off my back.

Sorry for the delay.

> 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...)

> 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. :)

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...

Rob

 1447427312.0