[issue35522] os.stat().st_ctime and time.time() mismatch

[Steven D'Aprano]

Steven D'Aprano <steve+python at pearwood.info> added the comment:

In the future, please describe your problem here, on the bug tracker, not just by linking to Stackoverflow.

You asked:

"Why is the file creation time [less than] the time measured before it is created?"

(You actually say "greater than" on Stackoverflow, but the example given shows you mean less than).

ctime does not mean "creation time" on Linux systems.

https://www.unix.com/tips-and-tutorials/20526-mtime-ctime-atime.html

https://stackoverflow.com/questions/27549217/ctime-atime-and-mtime-how-to-interpret-them

As for the ctime being earlier than the pre-recorded timestamp, I'm confident that will have something to do with the resolution of ctime versus time.time.

The time.time() function may have a resolution of as little as 1 second on some systems:

https://docs.python.org/3/library/time.html#time.time

so the fraction after the decimal point could be more or less random. Alternatively, the resolution of ctime may not be the same as time.time(). See the documentation:

https://docs.python.org/3/library/os.html#os.stat_result

I don't think this is a bug, I think this is an unavoidable consequence of the interaction between two different time measurements with slightly different resolutions. If you believe differently, can you explain why you think it is a bug?

Since time.time() simply returns the time according to the OS, and os.stat gives the ctime as recorded by the file system, I don't think there is anything Python can do about this even if it is a bug. It would be a bug in the OS or file system.

If you disagree, please explain why.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35522>
_______________________________________