How (Exactly) does VIRB Edit deduce the start time of a video file?

VIRB Edit does not look at the metadata of videos taken with a non-VIRB. For non-VIRB video we only look at the filesystem timestamp of the video on the device at time of import.

Thanks Wurth, that helps. So, it looks like you're taking the local filesystem modification time, subtracting the length of the video, and treating that wall-clock time as if it's UTC. Is this intended? It seems wrong.

I tested with a video taken at 1:38PM in Japan (UTC+9). The file system modification time (in the local timezone) is "Fri Oct 14 13:43:15 2016", and after loading that 5-minute video into VIRB, the relevant movie.plist file includes:

<key>CreationDate</key>
<date>2016-10-14T13:38:15Z</date>

That'd be correct if my local timezone were UTC, but it's UTC+9. Converting from the local timezone to UTC for display in the <date> field should have resulted in 2016-10-14T04:38:15Z.

In the same plist file, we have
<key>MediaStartTime</key>
<real>1476452295</real>
which seems to be a Unix Timestamp that translates to the same 1:38PM UTC Time.

When I view the clip with a clock overlay, it presents the time as 10:38PM, meaning that part of the system *is* taking the timezone into account when converting from the UTC time to local time. That's good, so the only problem is that a timezone is being incorrectly applied upon import.

Timezone stuff can be very confusing until it "clicks" with the developer. I'm new to video, but have dealt with geoencoding photos in Adobe Lightroom for a decade, so I'm well versed with best practices, in case the developer in charge would like to chat. One thing that's critical to keep in mind is that internal representations of time like a Unix Timestamp or a CocoTime on OSX are timezone-free concepts... there is no timezone associated with these. A timezone comes into play only when converting to or from a human-readable wall-clock representation of the time. Getting this important point confused trips up a lot of developers. I don't know how VIRB accesses the timestamp of the video, but it's almost certainly getting a CocoTime (in the case of OSX) from the file system, which is a timezone-free concept, so there should be *no* timezone conversion going on, unless you want to present the time in a human-readable form like the <key>CreationDate</key> above.

Going back to my example, when I updated the plist file manually, to remove 9*3600 seconds from the MediaStartTime, everything then worked perfectly in VIRB and the video meshed with the GPX file from my Edge 820.

I believe the 10:30pm you're seeing with the clock overlay is coming from the G-Metrix file associated with the video. The G-Metrix file is UTC based, but only if you get a gps lock. If your edge didn't have a gps lock before recording started, then it's time could be off -- possibly using local time instead of UTC time. If the MediaStartTime is showing 1:38PM as UTC start time instead of 4:38AM, then that makes me think you didn't have a lock. Unfortunately, we don't have any way of allowing you to adjust the time. We allow you to manually align the tracks using GPS-Synch option under the G-Metrix Data tab when editing a video, but adjusting that won't affect the time displayed. I think the solution you found by adjusting the plist mediastarttime is the best solution at this time.

You can verify this by using the GMetrixConverter tool that is bundled with VIRB Edit. Select 'show package contents' on the VIRB Edit app, then look in the Resources folder for the GMetrix tool. You can run that against the matching fit file to see what the timestamp is there. You can find the imported fit files by looking in '~/Library/Application Support/Garmin/VIRB Edit/Database/n/GMetrix' -- replace 'n' with the highest number in the ...Database folder.

I believe the 10:30pm you're seeing with the clock overlay is coming from the G-Metrix file associated with the video. The G-Metrix file is UTC based, but only if you get a gps lock. If your edge didn't have a gps lock before recording started, then it's time could be off -- possibly using local time instead of UTC time.

This doesn't quite fit for a few reasons. I know you're not the engineer in charge of this, so I appreciate your effort.

The time is the link between video frames and data in the GPX file... VIRB somehow determines the timestamp it thinks applies to a particular frame of the video, and that's what's shown in the
the "time of day" gauge. For other gauges, VIRB looks to see whether that time matches up with any data it has from the GPX file. Whether it does or doesn't, the idea of the time for that frame is something that originates in VIRB (and in my case, as you pointed out earlier, that itself comes from the filesystem time of the video file). The time isn't *influenced* by the GPX file... the time is the key to looking up data *in* the GPX file.

You can test this by loading a video and an unrelated GPX file, and looking at the clock gauge.

The G-Metrix file is UTC based, but only if you get a gps lock. If your edge didn't have a gps lock before recording started, then it's time could be off -- possibly using local time instead of UTC time.

All timestamps in a GPX files are, by definition, presented in UTC. I think what you meant to say is that times in GPX files are accurately set by the satellites if you have a lock, but are set from the unit's clock (and so could be off, perhaps by a great amount) until you have a lock.

This would wouldn't have any effect on the clock gauge, since an incorrect time means looking up via the wrong key into the GPX data (perhaps finding nothing, or finding data from a different moment).

Back to the original problem, there's definitely a problem with timezones. It feels as if a "timezone adjustment" is being done on something for which the concept should not apply. It wouldn't surprise me if this timezone adjustment is done twice (once each way) for VIRB-originated video files, in the "two wrongs make it right" sense by an original developer who didn't fully understand the the concept of Unix Timestamps, but done only once for non-VIRB video files like the one here. Thus it makes it look like there's a problem with how non-VIRB video files are read. That may indeed be the case, but as I said, it smells like it's the other way.

If you scan the source code for any mention of timezones, you should see them come onto play only when directly converting to or from a human-readable string representation of a time (e.g. "2016-10-14T04:38:15Z" or the time/date used in the clock gauge). If you see any kind of "timezone conversion" of something that's already a Unix Timestamp, it's almost certainly a mistake of misunderstanding.