Incorrect captured-at detection

🪲 Bug
1

The algorithm mentioned How does PhotoStructure capture captured-at? | PhotoStructure is not actually working.
For some scanned photos which I don’t know the date I set date to be 1/1/1904. I chose this date because that’s the default data for mp4 video files without corresponding metadata. So 1/1/1904 is a magic value to represent an unknown date in my photo collection.

I attached the image that has this magic date set

$ exiftool -a -G -ee -args -time:all 0072.jpg
-File:FileModifyDate=2021:01:04 12:50:35+02:00
-File:FileAccessDate=2021:02:22 14:53:07+02:00
-File:FileCreateDate=2021:01:04 12:50:35+02:00
-EXIF:ModifyDate=1904:01:01 12:00:00
-EXIF:DateTimeOriginal=1904:01:01 12:00:00
-EXIF:CreateDate=1904:01:01 12:00:00
-XMP:CreateDate=1904:01:01 12:00:00+02:00
-XMP:MetadataDate=2021:01:04 12:50:35+02:00
-XMP:ModifyDate=1904:01:01 12:00:00
-XMP:DateCreated=1904:01:01 12:00:00
-XMP:HistoryWhen=2020:08:07 13:12:20+03:00, 2021:01:04 12:50:35+02:00
-IPTC:DateCreated=1904:01:01
-IPTC:TimeCreated=12:00:00
-Composite:DateTimeCreated=1904:01:01 12:00:00

But PhotoStructure shows it as Jan 4, 2021, 12:50 PM which indeed is one of values from the exif tags but it contradicts to the the statement from the link above

The oldest “valid date” wins.

Expected Behavior

Photo date should be Jan 1, 1904, 12:00 PM

Current Behavior

Photo date is shown as Jan 4, 2021, 12:50 PM

Steps to Reproduce

  1. Add file mentioned above to the PhotoStructure library
  2. Look at Captured at metadata

Environment

Operating system and version: Windows 10

PhotoStructure edition: PhotoStructure for Desktop

2

Howdy, and welcome to PhotoStructure!

The timezone extraction heuristics in exiftool-vendored result in a surprising (at least for me!) tzoffsetMinutes:

{
  DateTimeCreated: ExifDateTime {
    year: 1904,
    month: 1,
    day: 1,
    hour: 12,
    minute: 0,
    second: 0,
    millisecond: 0,
    tzoffsetMinutes: 122.06666666666666,
    rawValue: '1904:01:01 12:00:00'
  },
  tz: 'Europe/Kiev',
  tzSource: 'from Lat/Lon'
}

The tzoffsetMinutes is coming from the TZ lookup based on GPS Latitude/Longitude, and it turns out that the UTC +2:02:04 offset for that time period is correct!

image
image805Ă—377 36.6 KB

This causes the date fields that you set (correctly) to be ignored, as PhotoStructure thinks (incorrectly) that they’re invalid because the tzoffsetMinutes seems to be invalid.

This will be fixed in the next release.

Thanks for taking the time to write this up! :+1:

1 Like
3

I’m a bit of a time conversion/date conversion aficionado it terms of it seems I’ve spent more than my share of time programming around edge cases.

With that said, I’ve never seen this conversion… very interesting:-)

2 Likes
4

I fixed round-trip conversions between ExifDateTime and luxon’s DateTime in the new version of exiftool-vendored: :tada:

Version 1.0.0 handles your example file correctly now:

  {
    _PhotoStructureVersion: '1.0.0-alpha.0',
    capturedAt: {
      date: ExifDateTime {
        year: 1904,
        month: 1,
        day: 1,
        hour: 12,
        minute: 0,
        second: 0,
        millisecond: 0,
        tzoffsetMinutes: 122.06666666666666,
        rawValue: '1904:01:01 12:00:00',
        zoneName: 'Europe/Kiev',
        toDateTime: [Function (anonymous)]
      },
      localCentiseconds: undefined,
      offset: 122.06666666666666,
      src: 'tags:DateTimeOriginal'
   },
   ...
}

Thanks again for reporting this!

1 Like
11

Thanks to @mnaoumov for reporting this issue. Apologies for the delayed follow-up.

CapturedAt and timezone extraction have been substantially reworked since this report, both in PhotoStructure and in exiftool-vendored:

  • Timezone inference: GPS-based timezone inference, IPTC TimeCreated extraction, Nikon TimeZone encoding workaround, support for archaic and triple-deep IANA timezones (e.g. America/Indiana/Indianapolis), colon-less offsets, Unicode minus signs, and many edge-case fixes across dozens of releases.
  • Bad date filtering: Known-bogus dates like 2002:12:08 12:00:00 (a common Android bug) are filtered via the configurable badDates setting.
  • Filename date extraction: Expanded patterns for LG, dashcam, and action cameras.
  • Plausibility checks: Additional validation when DateTimeOriginal and CreateDate disagree.

Release notes: PhotoStructure v2026.4 | PhotoStructure

Please upgrade to v2026.4 or later and re-sync affected files. If captured-at dates are still incorrect, please open a new topic with example files.