FWIW, the stat structure in Linux does not include birth time [1]. It only gives you:

1. atime: The time of last access.
2. mtime: The time of last modification.
3. ctime: The time of the last change to the inode.

I assume the stat command is using a filesystem-specific method to get the birth time.

Anyway, I don’t think any of these stats is guaranteed to be consistent with the rest (or even correct). For example, it is common to disable atime tracking to improve I/O performance.

Assuming the data is accurate, I think the other comment about the file being a copy is the best explanation.

I don’t know what exact situation could have happened here but I imagine a copy could have also copied the metadata into a new file. So it creates a new file as the destination (setting the birth date), then as part of copying the file it copied the access and modify times.

There are ways this can happen even without the technicalities of date tracking on the Linux file system. Take, for example, Microsoft’s decision to store local time in the system clock. If you dual boot, and don’t configure either Linux or Windows to be consistent with the other, your clock will be off by one or more hours, unless you happen to live at UTC+00:00. Every modern computer users NTP to automatically correct itself, but it’s not uncommon to see tons of files with weird timestamps after booting Windows.

Even without dual booting, it’s possible your computer’s clock has drifted into the future when it was off, and got corrected later. That would explain seconds or minutes of differences.