Why the file date changes
Downloading or extracting an archive can assign new filesystem creation and modification times. That does not prove that every timestamp inside the video container was removed.
Inspect both the filesystem and QuickTime metadata before choosing a source value.
Google JSON can contain the intended capture instant
A supplemental sidecar may preserve a Google-managed timestamp or edit that is not reflected in the original video. Match that JSON conservatively using all ZIP parts and the recorded title rather than assuming the nearest filename belongs to the video.
Keep the original absolute instant and record an offset where the destination format supports one.
QuickTime fields are not photo EXIF fields
MP4 and MOV containers commonly expose media creation and modification fields that photo-oriented commands do not update. Some consumers interpret those values as UTC, while others combine container and filesystem information.
A repair engine should choose fields based on the actual container and then test the output in the destination application.
Keep Live Photo and Motion Photo resources in context
A short MOV beside a HEIC or JPEG may be the motion resource for a dynamic photo rather than an ordinary standalone video. Renaming or organizing it independently can break the pair.
Pair identifiers and other evidence should be evaluated before deduplication or date-based reorganization.
Verify several video sources
Test phone videos, edited exports, messaging-app clips, screen recordings and Live Photo resources. Compare the app timeline, container metadata and filesystem display after repair.
If a destination still shows the wrong time, identify which field it prioritizes before rewriting the library again.