David and I have spent a lot of time tinkering with the creation time on MP4's, and going back and forth with the folks who produce the metadata extractor. jAlbum 19.3 includes the latest version of M-E, though there are still some buggy aspects to it. But there's an unsolved, underlying problem. Suggestions are welcome.
Let's summarize. The people who created the MP4 standard made one spectacularly, jaw-droppingly stupid decision. The only timestamp in the MP4 metadata reflects UTC (a.k.a. GMT). Well, in theory, at least.
So, if I use my smartphone to shoot a video at 10:00 in Connecticut (GMT-5), the timestamp in the metadata is 15:00. That's very nice, but since there's no timezone information stored in the metadata, there is simply no way to determine the local time at which the video was taken.
But it gets worse. My Nikon doesn't know what time it is, other that what I tell it. So if I shoot the same scene at the same time as the smartphone video, the timestamp is 10:00. The camera has no idea what UTC is.
So, we now have two videos shot at the same time, but with two different timestamps, five hours apart. And lord knows what happens with a video you save from someplace like Facebook - I don't even want to think about that one, since FB routinely clobbers the metadata in files.
What about using the filename? On my phone, the file name reveals the actual local time. But that's just one device. My Nikon labels it DSC_1234.MOV - not very helpful.
What about using the file creation time, as reported by the OS? The danger there is that when you copy the video from the shooting device to your PC, you might end up with a new file creation time.
Letting the user change the internal MP4 timestamp might seem like a good solution, but as a general principle, device-recorded information should be left alone. File Explorer, for example, might be hopelessly confused by a media creation time that's been manually fiddled.
The only approach that would be reliable would be to allow the user to record a real, local media creation time, based on his own knowledge of where he was at the time. That could be stored by jAlbum in one of its .info files, and used if it's present, both to display the creation time and to sort album objects. Alas, that won't "travel" with the file, so if you use the same video in another project, you'll have to make the adjustment again.
That also means that you would have to "touch" each video individually. It might be possible to provide a way to say, "all of the videos in this project were shot in EST, so subtract five hours from all of the timestamps." But if the project contains a mix of videos, either shot in different time zones or shot with different devices, that would produce a muddle.
This is a subject of interest to me. However, I think a satisfactory solution would require changing metadata and I doubt this is possible unless the latest version of M-E has significantly improved capability with video files. (Or unless you want to use Exiftool - not Java I know, but neither is ffmpeg.)
For what its worth though I would suggest:
(a) Allow bulk changes of the same type (e.g. 'set offset to zero') to all videos selected in the front end and/or all videos in selected folder(s) and the folders’ descendants. Seems like a good compromise between having to "touch" each video individually and process all videos in one hit. (Maybe it would facilitate this if the changes were made using an "External Tool")
(b) I would have a slight preference for storing the local time in the .info files, rather than just the offset, for two reasons. First, given that generally the metadata creation times are a mess (e.g. videos shot on devices which do not have geolocation probably store local rather than UTC time), it would permit retrospective correction of the metadata without upsetting the local time in the .info file. Second, this solution would be compatible with any odd videos which do not have UTC metadata.
(c) Whatever solution is chosen, it would be cool if it permitted user-modification, via a tool, of the originalDate variable (by supplementing the AlbumObject api?).
Edited by: sburke on 02-Feb-2020 03:17 - clarified ‘selection’ idea
Definitely an improvement. Just a couple of words of caution to users:
First, it may still show a date that's one day off. You're on vacation in Hawaii, and on Sept. 21, at 18:00 in the evening, local time, you shoot a thrilling video of a lava flow bearing down on you. Your phone records the time as 04:00 UTC, Sept. 22. When you go home to Stockholm (UTC +1) and make your album, the timestamp will show as 05:00 Stockholm time, Sept. 22.
Second, most skins will use the date format you've specified under Settings > Advanced > General to display things like date metadata, so if you don't want the often incorrect times to be shown on your videos, you need to use a date format that shows only the date. But that will apply to everything, including images. You can't affect one but not the other.
To be clear, there's no "clever" way to fix this under program control - the needed information is simply not available in the file. Ultimately, only some sort of manual override ("Let me tell you when this video was shot!") would provide a complete solution.
Your method is forcing the format to be yyyy-MM-dd. What if the user has specified a date format for the entire album as MMM dd, yyyy (as I do, for American visitors)?
I'd hate to start trying to parse the date format string specified by the user to remove all references to h, H, m, and a, and use the resulting string to format the timestamp for a video. I get the feeling that's one of those roads to hell that's paved with good intentions. Best left alone.
A skin developer can allow the user to enter his own pattern.
I recall something like that in one of the old skins (maybe E+?), and it caused endless confusion, because dates might be shown in one format on an index page, but in a different format on a slide page. It was like Forrest Gump's box of chocolates - you never knew what you were going to get.
I could also make a convenience method that strips the time from the default date pattern. Perhaps that's best?
Probably a bridge too far. The better solution is to figure out a good way for users to enter a correct video time. That would take care of the one-day error problem, and would allow the use of the regular, album-wide date format.
(BTW, this problem gets even more interesting when you start throwing Daylight Saving Time into the mix - you can get one result if you make your album while DST is in effect, but a different result if you make the album two days later, after DST has reverted to standard time. It's a thrill a minute.)
... The better solution is to figure out a good way for users to enter a correct video time. That would take care of the one-day error problem, and would allow the use of the regular, album-wide date format.
A read/write field in one of the panels in edit mode would make correcting the date/time easier. Even a preloaded user variable to overwrite the extracted data should not be too hard for users to deal with.
... The better solution is to figure out a good way for users to enter a correct video time.
That goes in my eyes to far.
The date method introduced by David works fine.
If you really are interested in a very accurate creation time you should use the exif date / time with the GPS position as you see here.
A read/write field in one of the panels in edit mode would make correcting the date/time easier.
This would be useful for images, as well. I have sometimes forgotten to reset the date/time on my Nikon when traveling, which results in all the timestamps being hours off. It would be nice to be able to fix them within jAlbum. I usually don't want to display that kind of info in an album, but when I do....
And things like scanned images currently have no meaningful timestamp, beyond the file date or the digitized date - it might be handy to be able to plant an "originalDate" on them.
To clarify, I wouldn't allow any tinkering with the actual file EXIF information. This would be something in a .info file, or perhaps in XMP (to allow use of the files in other projects without having to do the manual correction again), that would override the "real" EXIF or video metadata.
I'd forgotten about that one. Useful, but I'm always a little hesitant to start messing with EXIF information. To me, that's information that the camera puts in the image file, and it shouldn't be editable. If you want to use some alternate information, that's fine, but changing the original file is often a bad idea.
Then again, as long as you're working with a copy of the original (in the project directory), rather than the true original, no harm is done. You can always get back to the original.
(I'm in the midst of reworking some older images, and being able to retreat to the untouched original is truly a life-saver. Always do your tinkering with copies. )