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.

  • 5
    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, 2017 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, 2018 at 15:40

4 Answers 4


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, 2011 at 22:05
  • I edited my answer. Nice catch. I would vote you up if I could.
    – Stephen
    May 7, 2011 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, 2011 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...)

For Linux Fedora 35 with BTRFS (the default filesystem) I see the following precision:

stat test1.txt

Access: 2021-11-25 19:48:58.254916839 +0000
Modify: 2021-11-22 09:54:48.694107073 +0000
Change: 2021-11-22 09:54:48.698107163 +0000
 Birth: 2021-11-22 09:54:48.694107073 +0000

It's not clear how accurate those values are though.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .