bug in x86/uclibc busybox touch

[Denys Vlasenko]

On Sunday 02 January 2011 14:25, Rob Landley wrote:
> On Thursday 30 December 2010 21:50:57 Denys Vlasenko wrote:
> > On Thursday 30 December 2010 03:32, Rob Landley wrote:
> > > On Tue, Dec 28, 2010 at 7:45 PM, Denys Vlasenko
> > >
> > > <vda.linux at googlemail.com> wrote:
> > > > On Thursday 16 December 2010 13:54, Natanael Copa wrote:
> > > >> $ touch -t 0001010000 moo
> > > >> touch: invalid date '0001010000'
> > > >>
> > > >> the above works with coreutils touch and interestingly enough, with
> > > >> x86_64 uclibc busybox
> > > >
> > > > Because 1900-01-01 is a negative Unix time which doesn't fit
> > > > into 32-bit long.
> > >
> > > A 64 bit target shouldn't have the "year 2038" problem.  Midnight
> > > January 1 1970, plus or minus 68 years and change.
> > >
> > > > "busybox touch -t 0112130000 file" works,
> > > > and sets t=-2147475600 (0x80001f70).
> > > >
> > > > Previous day, -t 0112130000, doesn't.
> > >
> > > If you ls -l the file "moo" after creating it above, its date is
> > > 01-01-2000.  Not 1900.
> >
> > In busybox touch, it will be 19xx (on 64-bit machines,
> > where date 1900-01-01 fits into time_t).
> 
> It turns out SUSv4 specifies this:
> 
>   http://pubs.opengroup.org/onlinepubs/9699919799/utilities/touch.html
> 
> 69-99 is prefixed with "19", 00-68 is prefixed with 20.  (That way, it never 
> creates a negative epoch.)
> 
> Personally, I'd do something based on the current year, say accept 
> "current-60" into the past and "current+40" into the future, since there's a 
> bias for historical dates over future dates.  But if SUSv4 is going to insist 
> on hardcoding in a new Y2K variant, that's its' stupid perogative.

Good idea. I implemented it in git. Thanks.

-- 
vda