Repository navigation
Reject image capture times before 1970, rather than crash on them - #911
Merged
caglarpir merged 1 commit intoOct 24, 2026
Merged
Conversation
caglarpir
force-pushed
the
reject-pre-1970-capture-times
branch
from
October 24, 2026 12:55
bbeba84 to
d1b926a
Compare
Cameras without a clock write placeholder dates: some FLIR thermal cameras 0001:01:01 00:00:00, which mapillary#879 rejects as having no Unix time, and others a date in 1904 or 1969:12:31 19:00:00 (Unix time 0 in a time zone west of UTC). With a time zone offset, as when OffsetTimeOriginal is +01:00, 0001:01:01 00:00:00 does have a Unix time, before year 1 in UTC: the image passed, and writing its capture time to the description crashed the whole run with "ValueError: year 0 is out of range". The dates in 1904 and 1969 were taken as capture times: geotagged from a GPX, such an image was reported as decades outside the track. The EXIF, XMP and ExifTool readers now pass over a capture time before 1970, in the GPS date and in each EXIF date tag, so that the next date tag is read: DateTimeOriginal, then CreateDate, then ModifyDate. An image whose date tags all hold such dates has no capture time, and is reported as a geotagging error, "Unable to extract timestamp from the image". A capture time that cannot be written as a date no longer crashes the run either: it fails the image's validation. Checked process on 17,090 sample images from many camera models, with the default sources and with exiftool_runtime: only three change. A phone that writes a GPS date in 1961 beside the right DateTimeOriginal is now dated by the latter, 47 years later. The two FLIR images dated 0001:01:01 are still reported as having no capture time, without the date in the message. Given an OffsetTimeOriginal of +01:00, one of them is reported the same way, where the run crashed.
caglarpir
force-pushed
the
reject-pre-1970-capture-times
branch
from
October 24, 2026 13:24
d1b926a to
0d2af34
Compare
caglarpir
added a commit
that referenced
this pull request
Oct 24, 2026
…en in #911 rejected capture times before 1970, so that the next date tag is tried, but left three cases: - An image whose only date was rejected lost the reason: "Unable to extract timestamp from the image", where the error used to end with ": invalid capture time 0001-01-01 00:00:00". - A time with a time zone offset was judged by its own date, not in UTC: 1970-01-01 00:30 at +02:00, which is 1969-12-31 22:30 in UTC, was written as a 1969 capture time, and 1969-12-31 23:30 at -01:00, which is 1970-01-01 00:30 in UTC, was rejected. - A time in year 10000 in UTC, such as 9999-12-31 23:00 at -05:00, has no date that a description can be written with. Geotagged by a GPX, the error that names the time of an image outside the track could not write it either, and stopped the run with exit 15 and no description. A capture time is now valid from 1970-01-01 00:00 in UTC for a time with an offset, and as it is for one without, up to the end of year 9999 in UTC. A date tag that gives another time is still skipped for the next one; when none gives a valid time, the error names the first rejected one again. The time of a naive date, which is read in the local time zone, is checked once converted too, so that no capture time before 1970 or after year 9999 in UTC is written. The GPX error that an image is outside the track names a time that cannot be written as a date by its Unix time, so that a time offset that moves an image past year 9999 fails that image, not the run. Checked process with the default sources and with exiftool_runtime on 17,090 sample images from many cameras: the entries are the same, but for two images dated 0001-01-01, whose errors name that date again. With a GPX, the image in year 10000 in UTC gets an error entry and the run exits 0, and so does an image moved past year 9999 by --interpolation_offset_time. video_process and process of a GoPro and a BlackVue video do not change.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #910; review the last commit.
Cameras without a clock write placeholder dates: some FLIR thermal
cameras 0001:01:01 00:00:00, which #879 rejects as having no Unix time,
and others a date in 1904 or 1969:12:31 19:00:00 (Unix time 0 in a time
zone west of UTC). With a time zone offset, as when OffsetTimeOriginal
is +01:00, 0001:01:01 00:00:00 does have a Unix time, before year 1 in
UTC: the image passed, and writing its capture time to the description
crashed the whole run with "ValueError: year 0 is out of range". The
dates in 1904 and 1969 were taken as capture times: geotagged from a
GPX, such an image was reported as decades outside the track.
The EXIF, XMP and ExifTool readers now pass over a capture time before
1970, in the GPS date and in each EXIF date tag, so that the next date
tag is read: DateTimeOriginal, then CreateDate, then ModifyDate. An
image whose date tags all hold such dates has no capture time, and is
reported as a geotagging error, "Unable to extract timestamp from the
image". A capture time that cannot be written as a date no longer
crashes the run either: it fails the image's validation.
Checked process on 17,090 sample images from many camera models, with
the default sources and with exiftool_runtime: only three change. A
phone that writes a GPS date in 1961 beside the right DateTimeOriginal
is now dated by the latter, 47 years later. The two FLIR images dated
0001:01:01 are still reported as having no capture time, without the
date in the message. Given an OffsetTimeOriginal of +01:00, one of them
is reported the same way, where the run crashed.
Unit and integration tests, doctests,
mypy --python-version 3.9,ruff check,ruff format --checkandusort diffare clean.