bug#8572: du/bigtime skip reason

[Jim Meyering]

Bruno Haible wrote:
> Hi Jim,
>
>> That use of touch has to depend on the file system since it sets
>> stat.st_mtime and stat.st_atime.
>
> But why is (in 64bit mode) 'touch' accepting a date that 'date' rejects?
>
> $ coreutils-8.12-64bit/src/touch -d @922337203685477580 future; echo $?
> 0
> $ coreutils-8.12-64bit/src/date -d @922337203685477580
> coreutils-8.12-64bit/src/date: time 922337203685477580 is out of range
>
> If printing a date is harder than assigning that date to a file, how is then
> "ls -l" doing it?
>
> $ coreutils-8.12-64bit/src/ls -l f*
> -rw-r--r-- 1 bruno users  48 31. Mär 01:57 foo1.c
> -rw-r--r-- 1 bruno users 244 31. Mär 01:57 foo.c
> -rw-r--r-- 1 bruno users   0 922337203685477580 future
>
> Hmm. A single column instead of 3 columns? Wouldn't it be better to print
>
> -rw-r--r-- 1 bruno users   0 10. Sep 29227704432 future
>
> Then programs which expect 3 columns for the date will continue to work.
>
>> On systems with 32-bit st_*time
>> fields, touch has to diagnose failures like the above when the
>> supplied value is too wide for a 32-bit slot.
>
> So, this means 32-bit programs cannot reliably read the date of a file?
> Oh indeed:
>
> $ coreutils-8.12-64bit/src/ls -l future
> -rw-r--r-- 1 bruno users 0 922337203685477580 future
> $ coreutils-8.12-32bit/src/ls -l future
> -rw-r--r-- 1 bruno users 0 13. Okt 1942  future
>
> So, the error message "file system cannot represent big time stamps" was 
> wrong;
> instead: "the touch program's time_t type cannot represent big time stamps"
> would have been correct.

Right.  Though actually it's the type of timespec.tv_sec (time_t)
that matters, and that is selected by you when you choose to build
32- or 64-bit binaries.