When I ask jAlbum to List metadata on a video, the Mp4 video.Creation Time is always shown as GMT, rather than as the actual camera time. Similarly, mouse-hovering on the "info" icon on the thumbnail displays the Camera date as GMT. Not very useful.
So far, I haven't figured out how a skin can access the metadata fields on videos (see https://jalbum.net/forum/thread.jspa?threadID=55286), so this hasn't become a "real world" issue. But trying to sort on Camera date could produce some odd results if the video is mixed in with still images shot at the same time.
...trying to sort on Camera date could produce some odd results if the video is mixed in with still images shot at the same time.
Confirmed that this is a bug. I shot a video with my phone at 11:00 AM EDT, and took a still image a couple of minutes later. Added both to an album project, and told jAlbum to sort by camera date. It puts the still image first, because it thinks the video was shot at 4:00 PM.
I can see the correct time in the file name itself, but wouldn't you consider it a pretty special case to extract the time from the file name?
I'm not suggesting that - it might be OK for videos from this particular device, but not from anything else.
But it appears to be the only place that the actual camera time is recorded. No problem with my Nikon - the metadata reflect the actual, real, in-camera local time. I'm amazed that other devices don't seem to be storing this information anywhere.
So, to summarize, the only time stamp in the metadata is given as UTC. There's nothing in there that tells us what time zone the video was actually shot in.
We're left with only two options, neither of them very satisfying. jAlbum and/or the metadata extractor could assume that it was actually shot in the time zone of the user's current location. That would be fine if that were true. For my "bear crossing the road" movie, it would be correct. But for a video shot in the hills above Sils-Maria, that would be six hours off. The UTC timestamp in the metadata would be one hour off, because Sils is UTC+1, and converting it to UTC-5 would just make it even worse.
ETA: And option 2 is to use the UTC time, which will always be wrong unless the video was shot in Greenwich.
I suppose what's needed is a nice, friendly tool (i.e., not some obscure command line nonsense) that lets the user change the camera date, both for images and for videos.
I sometimes forget to reset my Nikon to the local time, and all of my Alpine shots are off by six hours, so it would be nice to be able to correct those. And my S7 videos are all retaining only UTC time, which is almost never right, so ditto on the ability to correct them.
Of course, it's an issue only when you either display the metadata, or, more important, when you're trying to sort your album objects by camera date. The JPG's from my S7 actually do show the correct camera date - it's only the videos that don't!
BTW, I can fix this with exiftool, as long as I'm willing to put up with the consequences. In short, I can reset the Media Create Date based on the local time where I simply know the video was shot. jAlbum then sorts it correctly WRT other files (like JPG's shot at the same time).
The downside is that other applications then do weird things. Windows File Explorer, for example, is still assuming that the timestamp is UTC, and then corrects it for my local time zone. That, of course, now yields a bad result. But given that File Explorer shows a different creation date if I simply pick up my PC and move it to another time zone, it's not providing any useful information, anyway.
As far as I can tell, there really isn't any useful time zone information in the file. Only the file name reveals the actual shooting time, since the smartphone did know where it was at the time!
It's worse than that. The "bear" video was recorded at 15:36 EDT. Checking the creation time with exiftool shows 19:36 UTC. That's correct, though not very useful. jAlbum shows:
Mp4.Creation Time=Sun Jun 10 20:36:49 EDT 2018
That's neither UTC nor EDT. It's some other value (CEST?), which is neither correct nor useful. Earlier, I was forgetting about daylight saving time, and mistakenly thinking that 20:36 was the correct UTC time - it's not, since UTC doesn't observe daylight saving time.
So what should jAlbum display? The two choices are to grab the recorded UTC timestamp and roll the dice, or to grab the UTC timestamp and adjust it to the current timezone of the jAlbum user.
The second option gets even more interesting when you try to account for DST. If you made the album in June, you'd get a different timestamp than you would if you made the album in December.
I shot a quick test video this morning, just to see if anything had changed in the S7's software since last year - output from exiftool attached. But no, the only video creation time info is UTC.
The file modification date, frustratingly, shows the correct local time, including the time zone offset from UTC. I have no idea, however, whether that's consistently reliable in an MP4. If so, jAlbum could use it. And the file name is also correct and usable, and that seems to be a standard (exiftool can convert it into time values, so it must be very common). The test video: https://jgromit.jalbum.net/20190713_070734.mp4
Or maybe jAlbum should look for the GPS coordinates, and provide true sun time.