On Fri, Nov 13, 2015 at 7:08 AM, Rob Landley <[email protected]> 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. _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
