Faced with the utter confusion caused by trying to figure out the interactions of the Sony HDR-AS30V time settings, I set it to local time, Time Zone GMT+0, DST off, enabled the GPS receiver, disabled the auto-off battery saver, and parked it outside with a nice view of the sky.
About ten minutes later it achieved GPS lock, which suggested the time wasn’t terribly wrong. After locking, the camera set itself to the current local time +1 hr, TZ = GMT-5, DST off; it apparently runs an embedded Linux distro, so it can convert from geographic location to time zone easily enough. It cannot know about DST, so I set DST on, the time jumped -1 hr, and it’s now set to local time, TZ = GMT-5, DST on.
A short movie produces this metadata:
exiftool MAH00046.MP4 | grep -i date
File Modification Date/Time : 2014:09:02 17:58:49-04:00
File Access Date/Time : 2014:09:02 16:59:51-04:00
File Inode Change Date/Time : 2014:09:02 16:59:51-04:00
Create Date : 2014:09:02 20:58:41
Modify Date : 2014:09:02 20:58:48
Track Create Date : 2014:09:02 20:58:41
Track Modify Date : 2014:09:02 20:58:48
Media Create Date : 2014:09:02 20:58:41
Media Modify Date : 2014:09:02 20:58:48
exiftool MAH00046.MP4 | grep -i zone
Time Zone : -04:00
ll MAH00046.*
-rwxr-xr-x 1 ed ed 18M 2014-09-02 17:58 MAH00046.MP4
-rwxr-xr-x 1 ed ed 11K 2014-09-02 17:58 MAH00046.THM
ll -c MAH00046.*
-rwxr-xr-x 1 ed ed 18M 2014-09-02 16:59 MAH00046.MP4
-rwxr-xr-x 1 ed ed 11K 2014-09-02 16:59 MAH00046.THM
ll -u MAH00046.*
-rwxr-xr-x 1 ed ed 18M 2014-09-02 16:59 MAH00046.MP4
-rwxr-xr-x 1 ed ed 11K 2014-09-02 16:59 MAH00046.THM
date
Tue Sep 2 17:13:44 EDT 2014
date -u
Tue Sep 2 21:13:47 UTC 2014
The camera quickly achieves GPS lock with DST on (so it’s still able to use its recent GPS ephemeris data) and doesn’t change any of the current time, Time Zone, or DST values (so it’s happy with all that).
Based on that short experiment:
- Internal Exif timestamp values are UTC
- Time Zone Exif value is (Actual Time Zone + DST)
- File modification is (local ending time +1 hour)
Some poking about shows that I misunderstood the “create” time, which actually holds the time when the file metadata changed, meaning there’s no way to tell when the file was created. I did know that the “access” time tracks the last time the file was opened: reading the Exif data will update the access time.
The +1 hr offset in the modification timestamp will (probably) vanish when DST goes off in the fall.
The Exif data contains the correct UTC times for the video’s Create and Modify dates, as well as the net Time Zone offset, which means I (well, a script using exiftool) can calculate the (UTC or local) time corresponding to the beginning & end of the video file. Indeed, exiftool can whack the file’s modification time directly from the Exif data:
exiftool '-FileModifyDate<ModifyDate' MAH00046.MP4
1 image files updated
Extracting still images proceeds from a time relative to the start, so the number of frames plus the calculated start time gives the actual time for that frame, modulo converting frames into hh:mm:ss.ff format and getting the addition correct.
Perhaps it makes more sense to set the modification time to the starting time of the video, thus simplifying the calculations:
exiftool '-FileModifyDate<CreateDate' MAH00046.MP4
1 image files updated
Both of those times are the UTC values, so a further adjustment based on the time zone would be in order. It’s not clear whether exiftool can perform that calculation internally or if it must be a two-step process.
A cheat may be in order: the thumbnail file modification timestamp matches the starting time of the corresponding video file. The script can base its calculations on the thumbnail timestamp. Of course, both of those are subject to the FAT-vs-DST problem.
More pondering is obviously in order.
For what it’s worth, the raw GPS log data from the camera lives in the PRIVATE/SONY/GPS/ directory, with a YYMMDDnn.LOG file name. It relentlessly accumulates two records every second:
@Sonygps/ver5.0/wgs-84/20140902205841.000/
@Sonygpsoption/0/20140902205842.000/20140902205842.000/
$GPGGA,205842.000,4139.5196,N,7352.4515,W,1,0,,,M,,M,,*5B
$GPRMC,205842.000,A,4139.5196,N,7352.4515,W,8.89,,020914,,,A*5E
$GPGGA,205843.000,4139.5177,N,7352.4501,W,1,0,,,M,,M,,*50
$GPRMC,205843.000,A,4139.5177,N,7352.4501,W,8.86,,020914,,,A*5A
$GPGGA,205844.000,4139.5160,N,7352.4488,W,1,0,,,M,,M,,*51
$GPRMC,205844.000,A,4139.5160,N,7352.4488,W,8.54,,020914,,,A*54
$GPGGA,205845.000,4139.5148,N,7352.4476,W,1,0,,,M,,M,,*5B
$GPRMC,205845.000,A,4139.5148,N,7352.4476,W,7.77,,020914,,,A*50
$GPGGA,205846.000,4139.5143,N,7352.4467,W,1,0,,,M,,M,,*53
$GPRMC,205846.000,A,4139.5143,N,7352.4467,W,6.61,,020914,,,A*5E
$GPGGA,205847.000,4139.5145,N,7352.4461,W,1,0,,,M,,M,,*52
$GPRMC,205847.000,A,4139.5145,N,7352.4461,W,5.17,,020914,,,A*5D
$GPGGA,205848.000,4139.5156,N,7352.4458,W,1,0,,,M,,M,,*55
$GPRMC,205848.000,A,4139.5156,N,7352.4458,W,3.31,,020914,,,A*58
The battery life is so terrible with the GPS on that I don’t plan to use it much at all, but at least now I know how to set the clock’s time…
The Smell of Molten Projects in the Morning 