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.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org