Images Missing "Date/Time Original" All Arbitrarily Assigned the Same Date

[grainsoflight]

I have 2000+ Images in my collection, many of which have had the "Date/TIme Original" Metadata altered in lightroom with dates ranging from 1-1-1900 to present. Everything that was altered shows up correctly. However anything that I did not make any changes to from the metadata that was written when I scanned the image gets dumped into 1-1-1970 on the timeline. When opening the information tab, there is no date info to suggest it should be in the 1970's, and when read in lightroom the image dates will be from sometime in the last 3 years when they were scanned.

Environment (please complete the following information):

• OS: Unraid
• Browser: Chrome

Used app version:

• docker:edge-alpine

[grainsoflight]

@grasdk do you think this might be related to my other issue? It seems when that field is missing it never moves to the next date/time field

[grasdk]

Hey.

Yes it can be related in the manner that your unaltered pictures store their date in a field not read by pigallery. There are an insane amount of date fields.

Can you provide a sample, or if not, then maybe show the output of running exiftool on one of the pictures?

For example this command could provide useful info

exiftool -G0:1 -*date* -*time* -*offset* mypicture.png

[grainsoflight]

@grasdk for instance, the previous image I submitted had it's date changed to some date in 1900 in lightroom, however this image never had it's capture date changed and instead should only include the date it was scanned into the computer

[grasdk]

thanks. It's a bug. The timestamp is actually stored in a field that is read already, but there is a bug in the code where the formatted timestamp is converted into a MS value.

It can easily be fixed, so I'll make sure to make a PR for that very soon.

[grainsoflight]

@grasdk Thanks, just to be clear, "Date Created" will still take precedence over "Create Date," correct?

[grasdk]

I think so, but I will try and make it clear with the PR. The tags have different names than the ones you mention, which are shown by your OS or image viewer.

In your photo, the tag xmp:CreateDate will be used. There are others that have higher priority, but they are not set in your photo.

[grainsoflight]

In the photo I posted on the other thread, there is a tag in exiftool called "Date Created" as well as one called "Date/Time Original" (both have the same values) that are targeted when you use lightroom to updated the image dates. These should take precedence over "xmp:CreateDate," which is the tag currently not being read

[grasdk]

I agree: The photo with the dog has these 3 tags: xmp:CreateDate, ModifyDate and MetadataDate. It should use xmp:CreateDate and it actually reads it, but then misinterprets it. The bug is in Utils.ts where the function I wrote assumed that timestamps do not contain offsets, but these are read independently in other tags. It's an easy fix, but I want to be sure that I don't introduce other problems ;-)

  xmp: {
    CreateDate: "2022-05-03T19:09:32-05:00",
    ModifyDate: "2024-03-22T18:02:39-05:00",
    MetadataDate: "2024-03-23T01:18:52-05:00",
    CreatorTool: "Adobe Photoshop Lightroom 13.2 Classic (Windows)",
  }

The metadata of the other photo from the other thread, does indeed have two other tags: photoshop.DateCreated and exif.DateTimeOriginal. exif.DateTimeOriginal has first priority in the metadataloader and photoshop.DateCreated is also pretty high up, and currently above xmp.CreateDate.

• The code doesn't make this very clear currently, so I think I will refactor it a bit, while fixing the bug anyway, to make priority clear and easy to change, if new information on proper date tag priority surfaces.

xmp: {
  ModifyDate: "2024-03-22T19:09:41-05:00",
  CreatorTool: "Adobe Photoshop Lightroom 13.2 Classic (Windows)",
  CreateDate: "2007-07-29T18:19:58",
  MetadataDate: "2024-03-23T01:17:49-05:00",
},
photoshop: {
  DateCreated: "1900-06-02T18:19:58"
},
exif: {
  DateTimeOriginal: "1900-06-02T18:19:58"
}

NB: There is much more metadata in the two photos than copied here, but these are all the dates.

[grainsoflight]

Perfect, exactly what I need it to do. Currently I had to let users knows that yes, Im aware these people didnt exist in the 70's, please dont email me about them XD

[grasdk]

I have a new PR here: #874. I added a test to show the problem and that it is solved. I actually discovered an extra bug this way. :)

It will probably conflict with my other PR because they both change both Utils.ts and MetadataLoaderSpec.ts, so there is probably a bit of extra work in either PR.

[grasdk]

@grainsoflight this should be fixed in next edge build

[grainsoflight]

@grasdk awesome, thanks! I noticed an update today but that must not be it because I didnt see any changes

[grasdk]

Let me know if it still doesn't work after next update :-)

[grainsoflight]

@grasdk I saw there was an update today, though there was no change

[grasdk]

Hey.

It was merged 5 days ago, and I just ran your photo through the code from current master branch:

Could it be the image? only edge-alpine has been updated: https://hub.docker.com/r/bpatrik/pigallery2/tags/

[grainsoflight]

Hmm, thats the branch I am pulling from, I dont see any changes as far as dates or captions

[grainsoflight]

I did confirm from within the program that is April 9th's build

[grasdk]

I just made sure to update as well. I added your? dog Koko to a test folder. It shows me 23rd of march 01:18:52 - 05:00

[grainsoflight]

Weird, I wonder if I need to scrap the container and start over

[grasdk]

indeed... hmm... And this is what is says under settings on mine:

[grainsoflight]

This

is what I got

[grasdk]

Same for me (but it shows the timestamp in my timezone both commit id etc is the same.

[grasdk]

also checked on mobile. All ok with the date there aswell ¯_(ツ)_/¯

[grasdk]

Could it be some browser caching? Try another browser or device, just to be sure.

[grainsoflight]

I tried on both my pc and phone

…

On Wed, Apr 10, 2024, 1:01 AM grasdk ***@***.***> wrote: Could it be some browser caching? Try another browser or device, just to be sure. — Reply to this email directly, view it on GitHub <#872 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHANMY4MXVABJU3KZ43NIP3Y4TIR3AVCNFSM6AAAAABFSR3GHWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBWGU4TINBZGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[grasdk]

Ok. Then I'm out of ideas except as you said, try from scratch. Luckily pigallery does not rely on the database as such. So you'll only loose your settings and your time for indexing. Perhaps try out with a second container first with a small album, before you scrap the one you use now?

Edit: Got one more idea: Try reindexing under settings?

[grainsoflight]

Reindexing didnt work either, complete rebuild of the container did though. Thanks for all your help, looks like everything is working

[grasdk]

Thanks, I'm glad to hear! :)

[grasdk]

@bpatrik @grainsoflight Suggesting this to be closed, as previous comments indicate the issue is fixed in edge version.

[bpatrik]

Thank you for the help!