Thanks for the explanation - I definitely think maintaining backward compatibility is a better approach. There is far too much breakage of software in linux as it is.
On Wed, 10 Nov 2010 11:02:30 -0700 Eric Blake <[email protected]> wrote: > On 11/10/2010 07:59 AM, IgnorantGuru wrote: > > $ stat -c %Z examplefile > > 1289397609.000000000 > > > > stat (GNU coreutils) 8.6 installed from Arch Linux repos, executing > > in a bash shell. > > > > This behavior changed recently - didn't used to have the .000000000 > > which breaks scripts that use stat. eg line 297: ((: > > 1289301692.000000000: syntax error: invalid arithmetic operator > > (error token is ".000000000") > > Technically, this is not a bug, since it was documented in NEWS: > > stat now outputs the full sub-second resolution for the atime, > mtime, and ctime values since the Epoch, when using the %X, %Y, and > %Z directives of the --format option. This matches the fact that > %x, %y, and %z were already doing so for the human-readable variant. > > However, it has already been discussed (extensively!) on this list > that it was somewhat an undesirable change, so for the > soon-to-be-released 8.7, the behavior is changing yet again: > > http://lists.gnu.org/archive/html/bug-coreutils/2010-11/msg00076.html > > stat's %X, %Y, and %Z directives once again print only the integer > part of seconds since the epoch. This reverts a change from > coreutils-8.6, that was deemed unnecessarily disruptive. To obtain > a full resolution time stamp for %X, use %.X; if you want (say) just > 3 fractional digits, use %.3X. Likewise for %Y and %Z. > > stat's new %W format directive would print floating point seconds. > However, with the above change to %X, %Y and %Z, we've made %W work > the same way as the others. > > so that %Z will once again omit nanoseconds, %.Z will print 9 > nanoseconds, %#.Z will print as many non-zero fractional seconds as > supported by the fs, and %#.3Z will truncate to milliseconds. >
