On my linux system if I display the current date "t1", touch a file "f" then display the modification time "t2" of that "f" I would expect t1 < t2.

But that's not what I always get when I execute this on my system:

date +'%Y-%m-%d %H:%M:%S.%N'; \
touch f; \
stat -c %y f

Example output:

2017-09-18 21:47:48.855229801
2017-09-18 21:47:48.853831698 +0200

Notice the second timestamp (stat) is before the first one (date): 855229801 > 853831698

My fs is ext4, but I also tried with a file on tmpfs, same effect. Why is it the case?


Some info about the setup

% which date

% which touch

% pacman -Qo /usr/bin/date /usr/bin/touch
/usr/bin/date is owned by coreutils 8.28-1
/usr/bin/touch is owned by coreutils 8.28-1

% uname -a
Linux machine 4.12.12-1-ARCH #1 SMP PREEMPT Sun Sep 10 09:41:14 CEST 2017 x86_64 GNU/Linux

% findmnt
TARGET                                SOURCE     FSTYPE    OPTIONS
/                                     /dev/sda1  ext4      rw,relatime,data=ordered
└─/tmp                                tmpfs      tmpfs     rw,nosuid,nodev
  • Now that I have asked the question I understand that date has a higher precision that mtime timestamps which are truncated, that explains why sometimes the truncated value is < to the previous date call. But still I feel that behaviour is counter-intuitive
    – piec
    Commented Sep 18, 2017 at 20:51

1 Answer 1


Per https://stackoverflow.com/questions/14392975/timestamp-accuracy-on-ext4-sub-millsecond :

ext4 filesystem code calls current_fs_time() which is the current cached kernel time truncated to the time granularity specified in the file system's superblock which for ext4 is 1ns.

The current time within the Linux kernel is cached, and generally only updated on a timer interrupt. So if your timer interrupt is running at 10 milliseconds, the cached time will only be updated once every 10 milliseconds. When an update does occur, the accuracy of the resulting time will depend on the clock source available on your hardware.

You must log in to answer this question.

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