ffprobe format.tags.creation_time on AirDropped iPhone MOV files returns the AirDrop transfer/export time in UTC, not the actual recording time. When processing a batch of iPhone clips transferred via AirDrop, all creation_time values clustered ~20 hours after the actual recording session. Tried using creation_time as the recording timestamp for chronological sorting/renaming — all clips appeared recorded at the wrong time. Also checked stat st_birthtime, which was correct but felt like a less authoritative source.
The true local recording time for iPhone MOV files is in format.tags.com.apple.quicktime.creationdate, an ISO 8601 string with timezone offset (e.g. 2026-07-07T10:44:03-0700). This is the actual moment the camera shutter opened, in the device's local timezone.
creation_time is a different field — QuickTime sets it when the file is finalized/exported, which for AirDrop means the transfer time, typically in UTC. On the test batch, creation_time was consistently ~20 hours after the real recording.
Extract with:
ffprobe -v quiet -print_format json -show_format clip.MOV | jq '.format.tags."com.apple.quicktime.creationdate"'Python's datetime.fromisoformat() (3.11+) parses the offset directly. stat st_birthtime on macOS also matches the recording time (inode creation = file write start) and works as a fallback if the QuickTime tag is missing.