PhotoStructure ignored the date metadata of some photos, marked them as taken in 2002

While I was browsing my library by date, I found a group of 62 assets, all tagged by the exact same date: Dec 8, 2002, 12:00 PM
These files have the correct date information inside the metadata and on the name, yet PhotoStructure still tagged them incorrectly.

Looking through the files, there doesn’t seem to be a pattern to them.
The dates vary between 2014, 2015 and 2016.
All were taken with my old Motorola XT1022 and uploaded to Google Photos using Picasa, but I have loads of other photos that fulfill these conditions that were tagged properly.

I am using PhotoStructure for Desktops 0.9.1 on Arch Linux.
Any logs I could provide to help debug this issue? I’ll be mailing a sample of the affected pictures to shortly.

Edit: The photos have been emailed.

Thanks for reporting this!

You can run the info tool to see what’s going on:

(add --verbose or even --debug for extra details), and look for the CapturedAt log messages.

You can also run exiftool -j -struct $path/to/file

I’m happy to take a look at a sample image you email to me, too.

PhotoStructure takes the earliest valid time it finds in the metadata. In these files’ case, CreateDate is set to 2002:12:08 12:00:00:

$ exiftool -CreateDate /home/mrm/Desktop/live/*.jpg
======== /home/mrm/Desktop/live/IMG_20141217_233300220-edited.jpg
Create Date                     : 2002:12:08 12:00:00
======== /home/mrm/Desktop/live/IMG_20141221_104133723-edited.jpg
Create Date                     : 2002:12:08 12:00:00
======== /home/mrm/Desktop/live/IMG_20150106_160343264-edited.jpg
Create Date                     : 2002:12:08 12:00:00
======== /home/mrm/Desktop/live/IMG_20150107_133241272-edited.jpg
Create Date                     : 2002:12:08 12:00:00
======== /home/mrm/Desktop/live/IMG_20150113_225416155-edited.jpg
Create Date                     : 2002:12:08 12:00:00
======== /home/mrm/Desktop/live/IMG_20150126_191717032-edited.jpg
Create Date                     : 2002:12:08 12:00:00
======== /home/mrm/Desktop/live/IMG_20150207_155319222-edited.jpg
Create Date                     : 2002:12:08 12:00:00
======== /home/mrm/Desktop/live/IMG_20160614_113451615.jpg
Create Date                     : 2002:12:08 12:00:00
======== /home/mrm/Desktop/live/IMG_20160614_114354045.jpg
Create Date                     : 2002:12:08 12:00:00
======== /home/mrm/Desktop/live/IMG_20160614_115211068.jpg
Create Date                     : 2002:12:08 12:00:00

You can remove the CreateDate tag from these files with exiftool: just run

exiftool -CreateDate= $path/to/file.jpg.

The next time PhotoStructure synchronizes those files, it should show the other date. Here’s what info says after I had ExifTool remove CreateDate:

    _PhotoStructureVersion: '1.0.0-alpha.0',
    capturedAt: {
      date: ExifDateTime {
        year: 2014,
        month: 12,
        day: 17,
        hour: 23,
        minute: 32,
        second: 59,
        millisecond: 0,
        tzoffsetMinutes: undefined,
        rawValue: '2014:12:17 23:32:59',
        zoneName: undefined
      localCentiseconds: 2014121723325900,
      offset: undefined,
      src: 'tags:DateTimeOriginal'

If this is a common issue in your library, would it be helpful to have the CapturedAtTags be a setting (so you could, say, remove CreateDate if you knew it was always going to be wrong)?

(How did it get set in the first place, I wonder?)

The current list is:

const CapturedAtTags = [
  // By the specification, DateTimeOriginal should be the time of the
  // shutter actuation, and CreateDate should be the time that the file
  // was written to the memory card (but not all mfrs follow the spec)

  // <>

  // First "*original*"
  "SubSecDateTimeOriginal", // (fractional seconds for DateTimeOriginal)
  "SubSecTimeDigitized", // (fractional seconds for CreateDate)

  "DateTimeOriginal", // (date/time when original image was taken)

  // Then "*create*"

  "CreateDate", // (called DateTimeDigitized by the EXIF spec)
  "DateCreated", // XMP tag


  // Then *modify*
  "SubSecTime", // (fractional seconds for ModifyDate)
  "ModifyDate", // (called DateTime by the EXIF spec)

  // Lightroom:
  // "HistoryWhen", // This is when history records happen, NOT when the file was captured!

  // Google Takeout (not really reliable, though)

  // This is the Google Photos upload time. That's not something we want, so
  // it's commented out. DON'T ADD IT BACK, FUTURE ME!
  // "creationTime"

More details here:

Thanks for the fast replies, they’re highly appreciated!

:eyes: :eyes: :eyes:

That would be very helpful, yes.
When PhotoStructure gains the ability to edit tags, it would be great if we could remove tags using the UI, bonus points if we could do it in bulk!

Quick question: Is the ‘Create Date’ tag a frequently utilized in people’s libraries?
Maybe it should be weighted less than the ‘Image Date/Time’ tag by default?

I wonder too. I have no idea of what could have caused this, other than a obscure bug inside Picasa (RIP!) or my old phone’s firmware.

Given that @Lars_Noschinski saw this issue too, and in both cases, there were other tags that had good contents, I think it’s safe to just remove CreateDate from the list of tags that PhotoStructure looks at by default. (see below)

For extra credit, the list of tags will be configurable via the new capturedAtTags library setting:

# +------------------+
# |  capturedAtTags  |
# +------------------+
# The following tags are examined to parse a file's captured-at time. The
# earliest valid tag is returned. See
# <> for details.
# PS_CAPTURED_AT_TAGS="[\"SubSecDateTimeOriginal\",\"SubSecCreateDate\",\"SubSecTimeDigitized\",\"SubSecMediaCreateDate\",\"DateTimeOriginal\",\"OriginalCreateDateTime\",\"DateTimeCreated\",\"DateCreated\",\"DateTimeDigitized\",\"MediaCreateDate\",\"DateTime\",\"SubSecTime\",\"ModifyDate\",\"photoTakenTime\"]"

This change will be in -alpha.3, which is a couple days out (I need to finish search).

1 Like

Would it be better to just include CreateDate at the end of the list? It would appear earlier it was midway in the list, but if it was “last” then it’s kind of an “if all else fails”.

Flip side, I can add it back if I want it, no biggie, just thought I would toss it out there.


I agree, it turns out that I had some examples that only had CreateDate, so removing that tag completely is a bit too blunt of a fix.

I added a special filter that discards CreateDate only if it’s this specific raw value.

Update: I’ve added a new setting, badDates, which defaults to ["2002:12:08 12:00:00"] (this will ship with v1.0.0-beta.10).

1 Like

@LiveLM here’s the parsing results for your files without this fix:

$ node dist/library/info --captured-at /home/mrm/Desktop/live2/* | grep Centiseconds
      localCentiseconds: 2002120812000000,
      localCentiseconds: 2002120812000000,
      localCentiseconds: 2002120812000000,
      localCentiseconds: 2002120812000000,
      localCentiseconds: 2002120812000000,
      localCentiseconds: 2002120812000000,
      localCentiseconds: 2002120812000000,
      localCentiseconds: 2002120812000000,
      localCentiseconds: 2002120812000000,
      localCentiseconds: 2002120812000000,

And with the fix:

$ node dist/library/info --captured-at /home/mrm/Desktop/live2/* | grep Centiseconds
      localCentiseconds: 2014121723325900,
      localCentiseconds: 2014122110413300,
      localCentiseconds: 2015010616034300,
      localCentiseconds: 2015010713324100,
      localCentiseconds: 2015011322541600,
      localCentiseconds: 2015012619171700,
      localCentiseconds: 2015020715531900,
      localCentiseconds: 2016061411345200,
      localCentiseconds: 2016061411435400,
      localCentiseconds: 2016061411521100,
1 Like

Dates look correct and they match the file names. Looks good to me!
When this fix makes it’s way into a release, I’ll try making a new library containing the affected files to make sure they get tagged correctly.

1 Like


I’ve just started using Photostructure and imported a fairly large library of photos. I’m using the Windows version V0.9.1 Beta. I’m very impressed with it.
I noticed a whole bunch of photos (>1000) ended up with their dates at the 8 Dec 2002 when they were taken much later (2013-2015).
Using windows filemanager the correct date/time shows, but using Exiftool the Create date field is 8 Dec 2002 12:00pm but the Date/Time Original field shows the correct date/time.
From what I can see on the forums there is a common theme to the camera that took the photos when this problem appears. They all appear to be Motorola phones. In my case it is a Motorola XT1068.

So now I know what has happened, do I just remove the create dates from all of the 1000+ photos and then go through each photo in Photostructure one by one and tell it to resync or is there a way I can do this in a batch?
If I need to remove the create date, do I do this on the file in the Photostructure library or do I remove it in the original location(s)? Some of these photos are in several locations and Photostructure has done a great job of deduping them :grinning:.
Does the fix you mention above make any of this easier, and can it be applied to just the photos in the Photostructure library on this date or do I need to re-import all of my photos? It took about 4 days to do the initial import so I am hoping this will not be the case.


Welcome to PhotoStructure, @Anths !

Could you email me an example image that isn’t being parsed correctly?

You may want to try a v1.0.0 beta build, there are a ton of bugfixes and updates. Instructions are in the latest beta announcement.

I’ll see if there’s a way way to make this less time consuming.


I have attached a sample of one of the photos that is not being parsed correctly.

I’ll have a look at the v1.0.0 beta build.


Thanks for your really quick reply. Much appreciated.

Being new to Photostructure I am not sure of all the features, but is it possible to define a small part of the Photostructure library to rescan without scanning the rest? Perhaps a way to scan a particular date range or by a particular tag or EXIF field?

Always feel free to ask if you can’t find something: more content on the forum makes it more likely for the Users Of Tomorrow to search and find an answer.

Good question! I answered this in a new topic: