At least for current Bushnell Trophy HD cameras, the metadata for videos does not contain an EXIF Date/Time Original field or an equivalent. This means Timelapse populates the video's datetime from the file's creation or modified time. In the case of a .avi copied directly from the camera's SD card the result is typically acceptable, or close thereto, as usually the computer running Timelapse is in the same time zone as the camera and the file gets marked with the datetime the video ended. However, this information is easily lost in the common case where the video is trimmed to save disk space. Also, if the image set's time zone is not the local time zone direct import of the .avi typically yields a correct datetime but a wrong UTC offset. The result is substantial manual labour devoted to checking file types, copying datetimes and offsets, and adjusting datetimes to account for lag in starting video and video lengths. Some of these steps are amenable to bulk edits but remain tedious, error prone, and difficult to undo if an error is made.
A more user friendly approach is to check to see if the image set contains the .jpg a camera produces immediately prior to an .avi (or .mp4 from .avi trimming) and set the video's datetime+offset to the .jpg's datetime+offset plus an estimate of video start lag. Some additional accounting may be desirable for the length of the video.
At least for current Bushnell Trophy HD cameras, the metadata for videos does not contain an EXIF Date/Time Original field or an equivalent. This means Timelapse populates the video's datetime from the file's creation or modified time. In the case of a .avi copied directly from the camera's SD card the result is typically acceptable, or close thereto, as usually the computer running Timelapse is in the same time zone as the camera and the file gets marked with the datetime the video ended. However, this information is easily lost in the common case where the video is trimmed to save disk space. Also, if the image set's time zone is not the local time zone direct import of the .avi typically yields a correct datetime but a wrong UTC offset. The result is substantial manual labour devoted to checking file types, copying datetimes and offsets, and adjusting datetimes to account for lag in starting video and video lengths. Some of these steps are amenable to bulk edits but remain tedious, error prone, and difficult to undo if an error is made.
A more user friendly approach is to check to see if the image set contains the .jpg a camera produces immediately prior to an .avi (or .mp4 from .avi trimming) and set the video's datetime+offset to the .jpg's datetime+offset plus an estimate of video start lag. Some additional accounting may be desirable for the length of the video.