This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: os.stat().st_ctime and time.time() mismatch
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.8, Python 3.7, Python 2.7
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: belopolsky, rbiswas143, steven.daprano
Priority: normal Keywords:

Created on 2018-12-18 05:32 by rbiswas143, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (3)
msg332040 - (view) Author: Rohit Biswas (rbiswas143) Date: 2018-12-18 05:32
Related Stack Overflow Question: https://stackoverflow.com/questions/53810984/mismatch-between-file-creation-time-and-current-time-in-python
msg332043 - (view) Author: Steven D'Aprano (steven.daprano) * (Python committer) Date: 2018-12-18 09:57
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.
msg332046 - (view) Author: Rohit Biswas (rbiswas143) Date: 2018-12-18 10:53
Thanks for your reply. It makes sense to me and was very informative.

I understand and would explain the problem in the bug tracker itself in the future.

I reported this as a potential bug but it seems like it isn't really. So, I'm resolving it as not a bug.
History
Date User Action Args
2022-04-11 14:59:09adminsetgithub: 79703
2018-12-18 10:53:55rbiswas143setstatus: open -> closed
resolution: not a bug
messages: + msg332046

stage: resolved
2018-12-18 09:57:52steven.dapranosetnosy: + steven.daprano
messages: + msg332043
2018-12-18 05:32:36rbiswas143create