Hello @taoyuanyuan, thank you for filing this issue!

In between the times reported, we need to account for those missing 1433.25 microseconds.
My biggest suspicion is that perhaps that difference arises because os.OpenFile invokes the "open" syscall which in its implementation uses nanoTime and doesn't account for monotonic time yet Go uses the monotonic time whenever it can.

I suggest that perhaps if such file time comparisons are tripping up your workflow, that perhaps you invoke .Round(time.Second) or after creating a file, you can invoke os.Chtimes https://golang.org/pkg/os/#Chtimes with the desired time rounded.

I can reproduce this too on my Linux box on the first try.

Kindly pinging @ianlancetaylor @ALTree @randall77 @aclements to help check over my hypothesis/suggestion and feel free to correct me.

@taoyuanyuan also it would be great to fill out the issue template as much and perhaps provide more information about your setup e.g. Linux version, distribution, what filesystem is being used etc. Thank you!

Never mind, it was just hidden in the HTML details, sorry for the false alarm asking you to fill out the template

I get the same behavior from a C program:

#include <stdio.h>
#include <time.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/stat.h>

int main(int argc, char* argv[]) {
  while(1) {
    usleep(900000);
    remove("/tmp/1");
    struct timespec now;
    while(1) {
      clock_gettime(CLOCK_REALTIME, &now);
      if (now.tv_nsec == 0) { break; }
    }

    int fd = open("/tmp/1", O_RDWR|O_CREAT|O_APPEND, 0644);
    struct stat s;
    fstat(fd, &s);

    if (now.tv_sec > s.st_mtim.tv_sec) {
      printf("%d %d\n", now.tv_sec, s.st_mtim.tv_sec);
    }
  }
}

Prints after some time:

1565196323 1565196322

So I don't think there's any bug here. Or if there is, it is the kernel not Go.

This does seem to be how the Linux kernel works. The implementation of clock_gettime(CLOCK_REALTIME, x), which is what the Go runtime calls for time.Now, makes sure to get a fully synchronized time. The implementation of the kernel internal current_fs_time, which is used to set the time in a newly created inode, doesn't bother. So on a multicore system the two times can be very slightly out of sync.

Closing because there is nothing we can do to fix this in the Go toolchain.