I'm seeing similar problems on my GrapheneOS phone as well. Seems to impact videos and photos differently. Sometimes tagged with local time zone, other times, UTC. -- but odd, because it's not just the wrong time zone, it can be the wrong day in UTC. IE videos I took last night are saying they're in the future -- for tonight.

I see similar issues on my end. In my case I my pictures where saved into iCloud Photos from a DJI Osmo 3, and when the app imported them into Immich the datetime was wrong by 2 hours.

I removed all pictures and tried to import them manually via
the web interface, same result.

Attaching one of the pictures that has that issue.

DJI_20240511164405_0094_D.JPG

Anyone from the project that can comment back?

Chiming in; same behavior here with older photos shot on a Motorola Moto G (1. Gen), additionaly it dates it far back (photo from 2016, Immich dates it as 2002)
For comparison, Windows Explorer seems to parse the information correctly.
I have my external library bound via a read only share, might this be a cause for the metadata not being processed correctly? (I am aware that manual changes to the metadata to these files cannot be saved, as it has no write access on the source folder)

EDIT: Okay, I just learned that Windows Explorer doesn't always read EXIF data.
In my case, windows explorer read the base file attribute but there ACTUALLY IS a "Created"-Date with an actual 2002-date for some reason (inspected with ExifTool). Hopefully that helps some people further diagnosing their metadata ✌️

2 weeks later: "Anyone from the project that can comment back?"

Are you on the latest version of the mobile app/server?

Was at the time of reporting, yes ..
.. and it's unfortunately a bit of a hassle to update so I refrained from doing so until had some feedback in this thread :-)

I am pretty sure the latest version was v1.105.0 two weeks ago. Can you help upgrade it and test it again? Also include the troubled file will help with troubleshooting as well.

I just updated to v1.105.1 and refreshed the metadata for my entire library, still having the same issue. Sample file in my previous comment.

Just updated to

• App version 1.105.1 build.140 and
• Server version 1.105.1

Tested and it is still borked ..

Attached sample file ...

IMG_20240605_002021.jpg

That becomes like follows in Immich ...

Almost 4 weeks later: "Anyone from the project that can comment back?"

@ygaeon The timezone is parsed based on a few heuristics, so it isn't easy to explain precisely which one is used. From my observation in the past, CalyxOS strips GPS data, which the parsing mechanism uses to identify the correct timezone

You can read more here https://photostructure.github.io/exiftool-vendored.js/#md:dates

Thanks @alextran1502 and yes, CalyxOS do but I'm using "OpenCamera" which does not strip GPS, afaik. Though, I fail to see why GPS would be needed in this case as the exif data is present. Please just use it when it is there?

$ identify -verbose IMG_20240605_002021.jpg 
Image:
  Filename: IMG_20240605_002021.jpg
...
    exif:DateTime: 2024:06:05 00:20:20
    exif:DateTimeDigitized: 2024:06:05 00:20:20
    exif:DateTimeOriginal: 2024:06:05 00:20:20
...

I checked the attached file, following your link @alextran1502 ...

Heuristic 1: explicit metadata

• My image doesn't have TimeZoneOffset
• exif:DateTimeOriginal: 2024:06:05 00:20:20 is set
• ModifyDate is NOT set
• None of OffsetTime, OffsetTimeOriginal, nor OffsetTimeDigitized is set.

Heuristic 2: GPS location

No GPS location available

Heuristic 3: UTC timestamps

• Neither GPSDateTime nor DateTimeUTC is set.

.. so I guess that exiftool-vendored would assume UTC in this case .. making all photos off by the 1-2 hours I see ..

In this case, would it not be possible to "attach" the timezone (from the mobile device) to the image/video being uploaded to the store?

Opened this over 4 months ago, still have the same issues. Anyone more knowledgeable have any comments or feedback?

Server Version: v1.114.0
App Version: 1.114.0 build.158

Some observations

Starting info:

• Our image has dateTimeOriginal
• Does not have GPS or any exif tags that represent the timezone

The way I observe immich working when it does not have any information related to timezone:

• Assume that the time (Date Time Original or whatever it has) is in UTC
• But uses the timezone of the server (set by an environment variable in the docker compose). Hence you see that GMT + 2:00. If the time in UTC was 00:20, then in the timezone the image was taken in, the local time was 02:20. Note: The browser and the app always displays the local time of wherever the image was taken. Hence, in the browser you see 02:20 GMT +2:00.

What would likely be an expected behavior is this:

1. Assume a timezone for that image
2. Then assume that the time (dateTimeOriginal or whatever the image has) is also in the same timezone it assumed in step 1

• If you assumed timezone as UTC in step 1 --> Also assume that the dateTimeOriginal is in UTC
• If you assumed timezone is the timezone of the server --> Also assume the dateTimeOriginal in server timezone. This is the better option in my opinion.

Many cameras without GPS just store DateTimeOriginal tags without timezone information. We often take pictures while on vacation in timezones that are not the same as the immich server and not in UTC. I don't think immich should ever assume what the timezone is. If it can't be determined from the image metadata, then the timezone should be explicitly stated by the user during import. This is only necessary because immich likes to attach a timezone to timestamps it stores. Other photo management systems do not care about timezone and the assumption is that the DateTimeOriginal is simply in whatever timezone where the photo was captured.

Correction to my previous comment - by timezone of the server, I actually meant the timezone the user sets using a env variable in the compose.

Also, I dont think that there is a solution without having a timezone attached to an image. I mean the entire concept of time is relative. So how would any application be able to provide a timeline view of images that can be taken in multiple timezones. Everything needs to be brought to a common reference, which is UTC, and we need the timezone to do it.

I agree it is nice to have the proper timezone attached to an image, but it was not deemed necessary when EXIF metadata was invented for use with digital cameras. I've been using the photo management site flickr for 20 years with images that don't have timezone information and the timeline features work just fine when you understand the time displayed is wherever the photo was captured. Flickr and other photo sites do not assume a timezone. Only the photographer knows the correct timezone in these cases so we need a way to pass that to immich during photo import if immich insists on storing timezone. If the photographer travels often, it can't be a fixed offset set from an env variable.

That is confusing. Maybe getting a bit off topic here - I still do not think flicker's timeline would work well ( it can still work. Bit is the timeline accurate - dont think so). What happen's if you upload 2 images.
A - 10 AM (no timezone information in the image. But it was actually taken in PST)
B - 11 AM EST.

Which image would come first in the timeline in Flicker? Flicker would need to assume a timezone for the images that dont have timezone OR just have B (11 am) come after A (10 am) just because of the time, which could most certainly be wrong.

Coming back to the original problem :), Immich does have environment variable that set the timezone of images that do not have a timezone. but it might also be worthwhile to be able to edit the timezone in the GUI i think.

It is a known drawback of EXIF that until recently it did not provide a way for cameras to record time-zone information. Any long-lived photo management system has had to deal with this. Flickr and others simply do not use timezone information for the timeline since historically it has not been available. Digital cameras existed for 20 years before geotagging became common and before the EXIF spec was updated to allow timezone with OffsetTimeOriginal. If you upload two photos to flickr, one with timezone data and one without, it will ignore the timezone and make no assumptions about timezone for the other. The timeline will still be correct and ordered exactly as captured. It would only be a problem if your timeline somehow contains photos captured by multiple photographers shooting simultaneously in different timezones.

Thanks for some activity in this issue .. :-)

@Sean-T-Moore : If it can't be determined from the image metadata, then the timezone should be explicitly stated by the user during import.

Well, if the timezone is missing in the metadata I think the closest truth would be the date and time and timezone set on the mobile device .. I mean, we usually update the time on our mobile device when we travel, right?

@ygaeon: I think the closest truth would be the date and time and timezone set on the mobile device

I import photos when I get home, not when I'm away in a different time zone. So mobile device timezone can't be used to set image metadata during import. Mobile devices really should be smart enough to set image metadata correctly already during image capture.

Maybe a section in the UI showing the latest import along files already stored with the option to modify them in batch, to check if everything is set ok or modify datetime settings accordingly.

Issues with parsing date/time incorrectly should go to #12650, potential feature requests (bulk modify assets) should be a feature request (pretty sure there already is one anyways)