information time of a picture

[SuperMotzer]

Hello,
Browsing my pictures and showing the information, don't catch how the shown time is calculated. Never the original time of the pic.
Thank you.

[SuperMotzer]

Seems that the picture time is corrected with the time zone. All pictures are indicated 1 or 2 hours laterthan in reality.
Pictures coming from several devices (Eos, iPhone) show the same trouble.
Using latest version in Alpine form.

[bpatrik]

The app uses the creation data as it is in the exif/iptc data (or the file creation date if none of those exists). Eg.:

pigallery2/src/backend/model/threading/MetadataLoader.ts

Line 71 in 753cc9d

metadata.creationDate = Date.parse(stream.tags.creation_time) || metadata.creationDate;

Using the local time, when it was shot.

[SuperMotzer]

Agree with you how it should work. But the results is not that. It seems to consider a timezone parameter

.

[SuperMotzer]

would appreciate some help for this topic. Mistake still available with latest-alpine on 11/24/21. Thank you.

[Sean-T-Moore]

I see this problem too using docker image: bpatrik/pigallery2:latest.
From the MetadataLoader code I see that pigallery2 correctly gets metadata.creationDate from my photos exif.tags.DateTimeOriginal. However, if my browser is running on a system with a timezone of anything other than GMT, the displayed photo time in pigallery2 Info will be incorrect by an amount equal to the TZ offset. For example, if my TZ offset is GMT-7, then the displayed time in pigallery2 is 7 hours before the DateTimeOriginal exif tag from the photo. First I thought maybe this is due to the fact that docker container is always GMT, but mapping my /etc/timezone into docker container did not fix this problem. So perhaps something in the frontend code is performing a TZ offset of the creationDate?

[SuperMotzer]

Hello Sean,
Yes, thanks for the confirmation. I did same analysis 10 months ago using the current version from that time. Also changing the docker TZ settings did bring anything. As bpatrik didn't respond to my concrete example, I just move away from pigallery2.

[bpatrik]

just seeing this.
I'm truly sorry that I cannot provide a better support for this app, but with work and life, I have less and less time for this project. I can spend a few hours here and there on this project lately.

[Sean-T-Moore]

Since this is apparent with a clean install, default settings, and using docker.... I would think this would affect everybody? It would be helpful to know if it doesn't affect some people so I would know if there is a setting or configuration that works.

[bpatrik]

related to #530

[bpatrik]

probably also related to #517

[bpatrik]

and pr #480 and issue #469

[bpatrik]

I do not have time for the near future to fix this. You can try to use an earlier version if that solves the issue or I'm happily accept PRs

[Sean-T-Moore]

I see, PR #480 fixed this issue. It was merged into master on 2022-05-01 but docker image bpatrik/pigallery2:latest has not been updated since 2022-03-12. The latest tagged release 1.9.3 predates the fix.
I was able to build and install from master today and verify this is fixed.
Thank you Patrik for the pointers and making this code available!

[bpatrik]

there were no recent release indeed, but the nightly builds:

[SuperMotzer]

Thanks so much for the information. nightly versions solve the problem and I use Pigallery2 again.