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 `@922337203685477580' > > 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 `@922337203685477580' > 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>
