When I use exiftool to extract the gps data from a mov file created by kdlinks x1 dashcam, the time stamps in the created gpx file are off by exactly one hour.
The actual time the mov was created (1st frame) was 9:00am EDT (Atlanta). This would be 8:00am EST. The gpx file created by exiftool shows the first frame created at 10:00am. NOTE: The gpx file actually has a time of 14:00Z, which converts to 10:00am EDT using -4 hrs as the adjustment for daylight time instead of -5 hrs for standard time. (I matched up the location Lat/Lon from the mov file with the generated gpx file to compare times)
The dashcam is set to the exact correct EDT time. When the Mov file is played in a windows app that shows the movie and displays the location and time stamp for each frame, it reports the correct actual time of 9:00am EDT for the first frame. That same location in the gpx file reports a time of 10:00am (14:00Z).
Do I need to modify the ediftool extraction command (shown below)?
exiftool -ee -fileOrder gpsdatetime -p gpx.fmt /Users/gopher/movies > out.gpx
I tried searching for this issue in the forum but did not find anything.
(Note - this post was modified from the original post to clarify about Z time in the gpx file.)
Thanks for any help.
zonedgopher
I don't know the reason for this problem, but maybe the -globalTimeShift option will allow you to shift the extracted times to match what you expect?
- Phil
Thanks much for the suggestion. I will try that and re-post on results.
I used the globaltimeshift feature to modify the original test.mov file - command below:
exiftool -ee "-datetimeoriginal<filemodifydate" -globaltimeshift -1 /Users/gopher/test.mov
This command modified the test.mov file ( renamed the original with "test.mov-original"). The modified test.mov file did have a different size than the original (just slightly larger). I then deleted the original mov file from the directory so only the modified version remained.
When I ran the command (exiftool -ee -p gpx.fmt /Users/gopher/ > out.gpx) to create the gpx file from the modified test.mov file, the gpx file created still reflected a time stamp of 14:00Z (10:00am edt). So, both the original test.mov and the modified test.mov generated a gpx file with a time stamp of 14:00Z (10:00am edt). As best I can tell the globaltimeshift command did not change the time by "-1".
Did I do this test properly?
Thanks
Zonedgopher
I didn't mean to modify your files. I meant this (with the original files):
exiftool -ee -fileOrder gpsdatetime -p gpx.fmt -globaltimeshift -1 /Users/gopher/movies > out.gpx
- Phil
I used the command in your last reply (on my original unmodified mov file)--->exiftool -ee -fileOrder gpsdatetime -p gpx.fmt -globaltimeshift -1 /Users/gopher/movies > out.gpx
This produced a gpx file with the same times as before -> the GPX shows 14:00Z time (10:00am EDT).
This is the same result I got in the gpx created with the command below:
exiftool -ee -p gpx.fmt /Users/gopher/movies > out.gpx
The gpx in this second case also reflects a time of 14:00Z (10:00am EDT)
I verified again that the original mov file, when played in a movie player app, shows the correct starting time of 9:00am EDT on the first frame, with the time incrementing, as the movie plays, on each frame.
I am not at all familiar with mov file formats, but could it be that the Kdlinks dashcam is creating the mov file in a format different than expected?
Thanks for your help.
Zonedgopher
In thinking about this issue I have thought of one possibility.
I believe the Kdlinks dashcam is creating the mov file using the local time that is set in the dashcam. In the example we have been working on that was 9:00am EDT.
The gpx file created by exiftool reports the time in Z (Zulu time). I am guessing (maybe incorrectly) that exiftool is reading the mov file local time and converting it to Zulu time.
In the case of EST (Eastern standard time) that adjustment would be +5 hours added to local time to get Zulu time. If exiftool is reading the 9:00am local time in the mov file and adding +5 hours it would generate a Zulu time of 14:00, which is what is in the gpx file.
However, since it is currently EDT (Eastern daylight time) the adjustment to get Zulu time is +4 hours. An adjustment of +4 hours would result in a Zulu time of 13:00, which would be correct based on the time the mov was actually created.
If exiftool is making the Zulu adjustment as I described above, does it always use +5 hours for Eastern time regardless of the time of year? Or does it look at the actual date and use +5 or +4 as appropriate for the time of year and whether daylight saving time is in effect?
Forgive my speculation here because I have no idea how any of the software works, yours or kdlinks. In fact I am not sure how you would know what time zone the mov file was made in, unless you look at the lon/lat locations in the mov file and calculate the time zone.
Thanks for your help.
Zonedgopher
Ah. I figured out why the -globalTimeShift function wasn't working for you.
The gpx.fmt file uses ${gpsdatetime#;DateFmt("%Y-%m-%dT%H:%M:%SZ")} to format the GPSDateTime itself. This unfortunately bypasses the -globalTimeShift function of the normal date/time formatting. Change this to just $gpsdatetime and add -d "%Y-%m-%dT%H:%M:%SZ" to your command and it should work. I will patch the DateFmt() function to apply the globalTimeShift in ExifTool 10.99.
You're right that this is probably a time zone problem, but it is too early in the morning for me to think this through in detail.
- Phil
I made the suggested changes and there is still no time change in the created gpx file.
In addition, the changes corrupted the gpx file format, making it un-readable by map program.
The gpx created with the changes contained the following time format:
<time>2018:05:21 14:00:51Z</time>
The above format is not readable. The correct format is:
<time>2018-05-21T14:00:51Z</time>
There are 2 differences: colons in date instead of dashes; and space between date and time instead of cap T.
I am posting below the exact changes I made in case I did something wrong.
I changed the gpx.fmt file as follows:
before change:
#[BODY] <time>${gpsdatetime#;DateFmt("%Y-%m-%dT%H:%M:%SZ")}</time>
after change:
#[BODY] <time>$gpsdatetime#</time>
I changed the command line:
before change:
exiftool -ee -fileOrder gpsdatetime -p gpx.fmt -globaltimeshift -1 /Users/gopher/movies > out.gpx
after change:
exiftool -ee -fileOrder gpsdatetime -p gpx.fmt -d "%Y-%m-%dT%H:%M:%SZ" -globaltimeshift -1 /Users/gopher/movies > out.gpx
The "after change" command has the correct dashes and the T in the format statement, but they do not appear in the gpx file.
Thanks for taking the time to help me on this. This is a great tool and I really need it.
Zonedgopher
You left in the "#" after "$gpsdatetime". You must remove this for -d to function. (The "#" suffix disables the print conversion.)
- Phil
I removed the # after the $ gpsdatetime in the gpx.fmt file. Everything else is the same as I listed in last post.
The created gpx file now has a time entry as shown below:
<time>m-H:SZ</time>
Before I removed the # sign after the $gpsdatetime, the time entry was as shown below:
<time>2018:05:21 14:00:51Z</time>
The correct time entry should be: (dashes in the date and a T before the hour of 14))
<time>2018-05-21T14:00:51Z</time>.
(of course the time shift function will change the T14 to T13 (-1 hour)
Did I change the command line properly for the -d function?
Thanks
Zonedgopher
Quote from: zonedgopher on May 23, 2018, 03:17:10 PM
Everything else is the same as I listed in last post.
...except that you are running from a .bat file this time, right?
Your change was fine, but you need to pay attention to details. You need a different command when running from a .bat file. In a .bat file, all "%" characters must be doubled. (You're lucky that I'm psychic and knew you were running from a .bat file or we could have wasted a lot more time on this.)
- Phil
That did it!
Sorry for the amount of time this took.
I actually did not know that % in a bat file had to be doubled. Have never run into that before.
Anyway, you are Golden for your help and I am glad you are psychic!!
Thanks for a great tool.
Zonedgopher.