Steven D'Aprano <steve+pyt...@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 <rep...@bugs.python.org>
<https://bugs.python.org/issue35522>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to