Getting some sort of modification date in a cross-platform way is easy - just call os.path.getmtime(path) and you'll get the Unix timestamp of when the file at path was last modified.
Getting file creation dates, on the other hand, is fiddly and platform-dependent, differing even between the three big OSes:
On Mac, as well as some other Unix-based OSes, you can use the .st_birthtime attribute of the result of a call to os.stat().
On Linux, this is currently impossible, at least without writing a C extension for Python. Although some file systems commonly used with Linux do store creation dates (for example, ext4 stores them in st_crtime) , the Linux kernel offers no way of accessing them; in particular, the structs it returns from stat() calls in C, as of the latest kernel version, don't contain any creation date fields. You can also see that the identifier st_crtime doesn't currently feature anywhere in the Python source. At least if you're on ext4, the data is attached to the inodes in the file system, but there's no convenient way of accessing it.
The next-best thing on Linux is to access the file's mtime, through either os.path.getmtime() or the .st_mtime attribute of an os.stat() result. This will give you the last time the file's content was modified, which may be adequate for some use cases.
Try to get the date that a file was created, falling back to when it was
last modified if that isn't possible.
See http://stackoverflow.com/a/39501288/1709587 for explanation.
if platform.system() == 'Windows':
stat = os.stat(path_to_file)
# We're probably on Linux. No easy way to get creation dates here,
# so we'll settle for when its content was last modified.
I've done my best to throw this together (and spent a few hours researching in the process), and I'm sure it's at least more correct than the answers that were here previously, but this is a really hard topic and I'd appreciate any corrections, clarifications, or other input that people can offer. In particular, I'd like to construct a way of accessing this data on ext4 drives under Linux, and I'd like to learn what happens when Linux reads files written by Windows, or vica versa, given that they use st_ctime differently.
Frankly, file creation time is usually fairly useless. When you open an existing file for write with mode "w", it's not replacing it, it just opens the existing file and truncates it. Even though the file contents are completely unrelated to whatever it had on creation, you'd still be told the file was "created" well before the current version. Conversely, editors that use atomic replace on save (original file is replaced by new work-in-progress temp file) would show a more recent creation date, even if you just deleted one character. Use the modification time, don't grub for creation time.
After many years, I've finally found a use for file creation time! I'm writing code to check a file naming convention in certain directories, so first of all I want to consider files that were first named after the convention was instituted. Replacing the entire contents (mtime) is irrelevant: if it was already there then it's grandfathered in.
Hi Mark. I propose a simplification. On Linux, returning stat.st_ctime is more pertinent because, in many cases, the time of last metadata change can be the creation time (at least ctime is closer to the real creation time than mtime). Therefore, you could simply replace your snippet by stat = os.stat(path_to_file); try: return stat.st_birthtime; except AttributeError: return stat.st_ctime. What do you think? Cheers
@olibre "at least ctime is closer to the real creation time than mtime" - no it isn't; this is something I've seen stated several times but it's totally false. Unless you've manually messed with the values in your inode, ctime should always be equal to or later than mtime, because an mtime change causes a ctime change (because the mtime itself is considered "metadata"). See stackoverflow.com/a/39521489/1709587 where I provide some example code to illustrate this.