bug#8572: du/bigtime skip reason

[Bruno Haible]

Hi Paul,

> > $ ./coreutils-8.12-64bit/src/touch -d @922337203685477580 future; echo $?
> > 0
> > 
> > $ ./coreutils-8.12-32bit/src/touch -d @922337203685477580 future; echo $?
> > ./coreutils-8.12-32bit/src/touch: invalid date format address@hidden'
> > 1

And the 'date' program's interpretation of the same date:

$ coreutils-8.12-64bit/src/date -d @922337203685477580
coreutils-8.12-64bit/src/date: time 922337203685477580 is out of range

$ coreutils-8.12-32bit/src/date -d @922337203685477580
coreutils-8.12-32bit/src/date: invalid date address@hidden'

> Is it the message "invalid date format" that's the problem?
> So you're suggesting that the message be improved to say "date out of range", 
> or
> something like that?  That would make sense; I'm just trying to make
> sure that's what you're asking for.

I'm asking for two things:
1) In tests/du/bigtime, to distinguish errors that are due to the 'time_t' type
   from errors that are due to the file system. When I get the error message
   "file system cannot represent big time stamps" I am led to believe that
   it's a problem with the 'ext3' file system, and actually it is not: the
   reason is some behavioural difference between 32-bit and 64-bit of the
   'touch' program.
2) To have a consistent interpretation of @922337203685477580 as an input date
   between 'touch' and 'date' and between 32-bit and 64-bit binaries on the
   same machine.

Bruno
-- 
In memoriam Heinz Droßel <http://en.wikipedia.org/wiki/Heinz_Drossel>