File timestamps precision is limited to one second for EXT3, one microsecond for UFS, and one nanosecond for EXT4 (at least according to experience). Is there any way to determine this based only on filesystem info?

The hacky alternatives I can think of are either to limit all my unit tests to seconds (which I do now), or to touch a bunch of files and checking which digits are zero in stat -c %x.

  • 4
    What you're asking about is precision, not accuracy. Your filesystem can say that a file's mtime is 2000000000.000001, but if your friendly neighborhood stratum 0 NTP clock says that it's actually 1500000000.000001 then you aren't very accurate even though you are precise to the microsecond.
    – Mike S
    Jan 31 '17 at 16:18
  • Careful: the ext4 on-disk format stores times in nanoseconds, and you can store times with that precision using utimes(), but the clock source the kernel uses to set atime/mtime/ctime is not that precise--e.g. ext4 uses current_time(), which uses current_kernel_time(), which is HZ/second granularity. (Probably about a millisecond--depending on your distro you may be able to figure out the value of HZ from 'grep CONFIG_HZ /boot/config-*') Feb 12 '18 at 15:40

As far as I know, there is no place that this information is stored on. It is coded into the filesystem. However, you can manually make a list of filesystems and the corresponding precision. I would use a case statement to test the filesystem id against your list of filesystems. You can make the default 1 since there are very few examples where precision is less than 1 second.

Older versions of FAT and current versions of zip use 2-second timestamp precision from what I have read online. However, I suggest you fact-check that.

You can get the id of a file's filsystem with the following command.

stat -f --format="%t" $file
  • 2
    %i is unique per each file system, e.g. if you have two ext4 partitions, each will have a different id.
    – Mikel
    May 6 '11 at 22:05
  • I edited my answer. Nice catch. I would vote you up if I could.
    – Stephen
    May 7 '11 at 3:45
  • Looks like this is the best available option - It would be interesting to know if there is an authoritative list like this online. I couldn't find one with a quick search.
    – l0b0
    May 9 '11 at 11:29

Normally you would be able to use statvfs or pathconf, but they don't seem to support any way to find out that piece of information.

Apparently such a feature is being discussed for a future POSIX standard

we will also file some aardvarks for a pathconf enhancement to return the granularity of timestamps on a per path basis.

Unfortunately, I can't see any clean way to do that today, not even in an OS-specific manner.

Any approach that tries to build a list of file systems and whether it supports sub-second resolution is dangerous. For example, ext4 seems to support nanosecond resolution if the inodes are 256 bytes, but not if they are 128 bytes.

Compiling a comprehensive and accurate list would be hard, may require root access, and it might change tomorrow. Which sounds harder than just running stat a few times to me.


I just implemented a detection for a file database. I first set the timestamp of a file to 1234 millis, and then read it again and check if it is 1234 (at least ms precision) or 1000 (second precision). The things I learned so far were:

  • XFS and EXT3: second precision
  • EXT4: millisecond precision
  • NTFS: 100ns precision (OK, got this from the docs...)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.