P: Handle video capture times for cameras obeying the Quicktime/MP4 standard

LR displays the capture times for video from many cameras in UTC, rather than in local time of where the video was shot, which is obviously less useful to users. Though the original sin was a poorly written Quicktime/MP4 standard that is inconsistently obeyed by cameras, LR could handle the situation much better with a small amount of effort.

The De Jure and De Facto Standards

The Quicktime/MP4 standard specifies that the time in the Quicktime:CreateDate field is in UTC, not local time, and the standard doesn't provide for a time-zone field as EXIF does. However, prior to smart phones and GPS-connected devices, most cameras recorded local time in Quicktime:CreateDate, not UTC, and many cameras still do.

But now, more cameras (but far from all) are following the standard. They fall into these categories:

1. Smart devices that connect and sync time with the Internet. These devices know both UTC and the local time zone.

Apple devices obey the standard, writing UTC in Quicktime:CreateDate but also writing local time and a time zone in the non-standard field Quicktime:CreationDate (sic):

[QuickTime] Creation Date : 2021:11:08 06:45:07-05:00

At least some Android devices (e.g. Samsung S23 Ultra and Nexus 5) obey the standard, but I don't know if some of them record the time zone somewhere (the Nexus 5 doesn't).

2. GPS-connected devices that sync time with the satellites. GPS doesn't provide them with a time zone, though some of them may allow the user to set a time zone manually.

At least some DJI drones write UTC in Quicktime:CreateDate.

3. Cameras requiring the user to set date/time and time zone manually.

Most (all?) Canons obey the standard, writing UTC in Quicktime:CreateDate, but they also write local time in EXIF:DateTimeOriginal, using the time zone set by the user.

Older Nikons (e.g. the D850) write local time in Quicktime:CreateDate, while the Z series writes UTC in Quicktime:CreateDate and local time in a Makernotes field, using the time zone set by the user.

Newer D cameras write UTC in Quicktime:CreateDate and local time with a time zone in XMP:CreateDate.

Newer Sonys (e.g. the RX100M7) write UTC in Quicktime:CreateDate and local time with a time zone in XML:CreationDateValue, where XML is a Quicktime Meta tag.

4. Cameras requiring the user to set date/time manually but don't allow time zone to be set.

Older cameras, including older Sonys are in this category. These cameras write local time in Quicktime:CreateDate.

Lightroom's Current Rules For Handling Video Capture Time

LR currently uses the following rules to display video capture time:

1. If the video was created by an Apple IOS device, LR displays Quicktime:CreationDate, the Apple-specific nonstandard field containing local time plus a time zone. Thus, LR displays local time for Apple devices.

2. If the video contains EXIF:DateTimeOriginal, LR uses that. This correctly handles Canons. At least one camera, the Fujifilm X-T4, writes the same time into both EXIF:DateTimeOriginal and Quicktime:CreateDate, but I don’t know if that's UTC or local time.

3. Otherwise, LR uses Quicktime:CreateDate. This causes UTC rather than local time to be displayed for many cameras, including many Nikons and DJI drones. For Sonys and other cameras that write local time to Quicktime:CreateDate, their capture times are displayed correctly.

Making Lightroom Better

With a small amount of effort, LR could do a much better job of handling this industry mess:

1. a. For Nikon cameras, use local time from Makernotes:DateTimeOriginal if it exists, otherwise XMP:CreateDate if it exists and has a time zone. The Z series has Makernotes:DateTimeOriginal, while at least some of the newer D series has XMP:CreateDate with a time zone.

LR already uses this general approach for Apple devices, reading a non-standard metadata field. Since Adobe already has legal agreements with Nikon to read Makernotes for raw processing, perhaps they would apply to reading Makernotes:DateTimeOriginal (XMP:CreateDate is an industry standard field, not Nikon-specific). But if Adobe needs a modified legal agreement, a small number of overpriced lawyer hours is surely worth the benefit to users, putting Nikons on an equal footing with Canons.

1.b. For Sony cameras, use local time from XML:CreationDateValue if it exists, otherwise use Quicktime:CreateDate. LR already uses this general approach for Apple devices, reading a non-standard metadata field.

2. Provide an option in Import > File Handling: Shift Video Capture Time By Current Time Zone. This would only be applied to those videos that don't have an explicit rule for recognizing local time (e.g. Apple devices). The option could be saved in import presets.

This option would work correctly when the video was taken in the same time zone as the computer running LR. It wouldn't work when the video was taken in a different time zone. But it's still much better than the current situation, in which the capture time is always wrong.

3. Provide a user-editable text configuration file that lists camera makes and models for which the video capture time should be automatically shifted to the current time zone. Adobe could optionally pre-populate it with known cameras that record UTC in Quicktime:CreateDate.

As with the previous option, this would still get wrong the capture times of videos taken in a time zone different than the computer running LR, but it's much better than the current situation in which capture times are always wrong.

4. If GPS coordinates are available and no other rule applies, use open-source libraries to map the coordinates to the time-zone offset of the capture time or use the Google Maps API (which Adobe has already licensed for LR). Shift Quicktime:CreateDate by the offset.

This would be useful for the large number of Android phones and drones that obey the Quicktime standard.

Updated 8/28/23 for newer Sony cameras.