Amoung the jobs of an operating system is to maintain the disk file system including the directory structure, file names and for each file, the file size and the pertitent date information for when the file was created, modified and potentially accessed. I have been editing some videos lately and after producing a MP4 using ffmpeg; I used PowerShell to set the file create and modified times to the date that the video was recorded. This makes it easier to sort and allows viewing software to display timelines, good things. MP4 files also have an internal date that is set by cameras to note the datetime of when the video was recorded. I was surprised to learn that Windows Explorer displays the MP4 date rather than the file date and this can be problematic if the MP4 file does not contain valid date data. This post describes the issue in detail and provides steps for adjusting all the dates to the same datetime.Notice the use of term "datetime" rather than "date" and "time". In Windows and its probably an ISO standard, computers store file dates and times as one field, which on Windows NTFS is a 64-bit signed count of 100ns periods since January 1, 1600. The point is that it can handle splitting a second up into 100 pieces intervals per second and 64-bits is a bit enough space that it can accurately store both date and time for a very long time. As users, we never see this and as programmers, we usually don't need to worry about the detail of the field, its a 64-bit number that represents the file's date and time in one go, "datetime". Since it's one field, comparisons of before, after and same become very easy and can be done in one operation and since its signed, you can ""subtract" datetimes to figure out how long it was between two times.
Windows stores 3 datetime fields for every file on disk
MP4 stores its own datetime of when the file was created - normally stored by a video camera assuming you remembered to set the clock!
On Windows NT systems, the Create date is not the date that the file was first created, it is the date that this specific file was created, so if you copy the file from one location to a new location, that new file will have a fresh Create date equal to "now" and if you then edit the image/video with a program, this will update the "modified" date and all concept of when the file was created will be lost. Image and video cameras work to solve this by storing the date that the picture was taken of video recorded directly inside the image/video file.
As a side note, the technique in PowerShell to adjust the fle create date back to what it is supposed to be is:
In my recent case, the files were MP4, videos of the kids in their younger days and I had imported these from analog camera to computer and after processing through a few different tools, the last step was using ffmpeg to convert to MP4. This worked great! Then I set the CreationTime to the historic datetime of the video being recorded and ... though I was done.
View with Windows Explorer and ... the DATE DID NOT TAKE!
Explorer is showing that the video's datetime is 12/31/1969 7:00pm. That isn't right!
Compare the GUI view to command prompt view. Never trust a GUI!
Command prompt has the "correct" datetime.
As the explorer GUI to show file details, and we have a match! It is listed as "Media Created" date.
And use EXIFTOOL to show the innerds of the data and we have a winner!
The dates inside the MP4 file are all zeros! Actually, this makes sense. I captured the video content from one tool, plumbed it through a few others, and out the other side, ffmpeg produced the MP4 file. By the time it got there, the only record of the datetime that the video was recorded was in the name of the file. The MP4 file has zeros as its internal record of when the file was created.
Sometimes things try to do too much
The job of an operating system is to maintain the file structure on disk. Esoteric concepts like what is in the files for video editing applications, is IMHO an application responsibility. BUT - Windows Explorer is trying to help out and is displaying the MP4 internal date rather than the Create, Modified, Accessed time from the file on disk. Explorer is trying a bit to be a video display application, something that really isn't its job. Then again, it can also show thumbnails for images and ... people like that. Is it something that SHOULD be in an operating system? The lines blur and we can all have a nice debate on whose job it is to display the video content and whose job it is to display the image/video content.
Back to reality - this is not showing the date that I want it to show and the solution is to either configure Explorer to show a different date field as date or to modify the MP4 files to have datetime information embedded. "B" is the better solution. I went looking on the internets and found this fine post on StackOverflow, link. Bingo! I am not the first person to have this problem. In the post, Edward Brey even provides Visual Basic source code to modify the MP4 datetimes to be any date you want. Awecome. Took a bit to compile that up and ran it and everything looked good, but I wasn't done.
In running the VB code to adjust the MP4 datetime, the file modified date was also modified, so I ran my PowerShell bat file one more time to modify the file date times and ... by magic, the MP4 datetime is now incorrect. For some files, off by 5 hours, for others, off by 4. A bit of study concluded that the 4 vs. 5 is daylight savings time or not of the date of the files set against the create time in the file. When PowerShell (.NET) is adjusting the CreateTime, it is also adjusting the MP4 internal create date! What? Why.
- I did not ask PowerShell to adjust the datetimes that are in the file contents, only the file "date". But, the embedded date in the MP4 file did change!
- And we're back to the job of operating systems vs. the job of applications, but this could be a very long diversion
And its worse. The MP4 datetime was "correct" per me in the before and after setting the datetime of the file create date, the MP4 datetime was now incorrect by a period of time equal to number of timezones away from GMT on the date that the file was recorded.
I studied this for about a day and concluded that MP4 internal datetimes are the datetime that the file was created/recorded/modified and that time shall always be ZULU! The VB code didn't know if the time I gave it was local time or GMT/UTC/Zulu, so it went with what it had. When the file CreatedData was set from PowerShell, the .net runtime decided to help out and ajust the MP4 datetime to match the create date on the file itself.
Okay, problem now understood and dates all adjusted. What is "odd" is that if PowerShell and .NET adjust the date of the MP4 file when the internal date is concluded "wrong", why doesn't it also do that when the internal datetime is zeros? Consistency here would be a win.
Please add your comments below. If you want the compiled version of the program to adjust the MP4 internal dates, drop a line and I'll send your way. email to joe at this domain.