Creation date is ambiguous

[roadelou]

In the sort_by_date functions of src/video_logging.py, you are doing a few time-related manipulations.

The way those manipulations are done (using localtime and strftime) are quite flawless, kudos for that :+1:

My issue isn't with how those manipulations are performed, but more about what they actually do. The help for the date command states :

The 'date' command sorts the files in the current directory by creation date.

Which is a great idea, but you don't specify here what you mean by 'creation date'. Is it :

• The date at which the video was taken ?
• The date at which the file holding the video was created ?

Obviously, the OS cannot report the first one (but maybe that this can be found in the metadata of the video :thinking: ?), so I think that you meant the second one.

I also believe that you looked on the internet how to get such a date and discovered that this is disappointingly not always possible :wink:

The name getmtime means "get modification time" (I think), thus os.path.getmtime will report the last time the file has been modified. Because the file at stake is a video (stored in a binary format) it is highly unlikely to be modified once it has been created, therefore using getmtime as a creation time makes sense :+1:

One caveat though : if the file is a copy of another video file, then the time reported by getmtime will be the date of the copy, because the copy is considered as its own entity by the filesystem. On Linux you could test that with :

# Creating a new file
touch test
# Getting information about the file
stat test
# Creating a copy of the file
cp test test_copy
# Verifying the information of the old file
stat test
# Looking up the information of the copy
stat test_copy
# Removing both files
rm test test_copy

But that does not mean that there is no hope :smile: On Windows at least, the function os.path.getctime will return the creation time of the file. So you could at least try to use getctime if you are running on windows. You can easily tell the OS at runtime with sys.platform.

Note that on Linux, getctime returns a time that is not the creation time of the file.

I do not have the means to confirm this, but I believe that if you upload a video from a smartphone :iphone: or any other camera :camera: to your computer, the time reported might be the time of the upload because this is when the file gets allocated in the filesystem.

Aside from that, if you haven't already done it, you should look at the metadata of the various video formats. Maybe moviepy already supports this. Regardless, a bit more clarity in the help and the documentation on what 'creation date' means would be nice.

[theodumont]

You got it, ideally I'd like to get the date at which the video was captured.

Using getmtime made sense to me because - as you said it - the file will not be modified as it is binary. While writing the code, I was curious too about the result of this function applied on a copy of a file, so I tested it (on Windows 💻). It seemed that the copy kept the modification date of the original file, whereas the creation date was modified and set to the date of the copy (and that's why I chose to use getmtime instead of getctime).

Thus, when importing videos from a camera to the computer, the modification date will never be altered, and will always be the date at which the video was captured by the camera.

But after reading your comment, I played with copy-pasting on Unix, and apparently the cp command hasn't the same behaviour on Unix and on Windows 🤔. You can test this if you have a Windows with WSL installed, for instance with Windows Terminal. In WSL, type:

mkdir foo
cd foo
# create file
touch file
# copy unix style
cp file file_copy_unix

and in a PowerShell terminal:

cd foo
# copy win style
cp file file_copy_win

Now, type:

stat file_copy_unix
stat file_copy_win

and you will see that the modify date of file_copy_winis the same as that of file. Apparently, you can use cp -p on Unix and it will preserve the time of the last data modification, acting like a copy-paste on Windows.

All this to say that I should have done my experiments both in Windows and Unix before decreeing that copying a file does not affect its modification date 😃

Anyway, on Windows, whereas the creation date is modified when doing all this stuff, the modification date isn't. If we want to stick with the classic os functions, I think there is nothing better we can do here. As you mentioned, it could be nice to check if the creation date can be found in the metadata of the file, and I will definitely take a look at this. It would give us a date that does not depend on the OS 👍

Thank you for your detailed comment!