[MEGATHREAD] Date/time/timezone issues

[jrasm91]

As everyone should know by now, photo and video metadata is a bit of a mess. On top of that, we're also now talking about timezones. Long story short, we know there will always be room for improvement in this area.

If you have an issue with:

• Photo or video showing up in the wrong place in the timeline
• Photo or video with the wrong date day, time, or timezone
• Photos or videos taken at the same time not showing up next to each other

Please post a comment in this discussion with the following, and we will happily investigate the issue.

• a zip of your file
• the expected date, including timezone
• current date produced by immich

EDIT: if you don't post the three points mentioned above, you're comment will simply be marked as off topic and hidden.

[mmomjian]

Can we also ask people to include their .env with the TZ variable and the output of date both on the host and in the immich_server container?

[C-Otto]

Africa/Abidjan always has the +00:00 offset and this name might be shown because it is the first match alphabetically, see #5897. When dealing with timezone issues, please have a closer look at the offset (+00:00 in this case) first. If it is wrong, this is a valid concern, If the name shown for the offset is wrong, that's just an UX issue.

[meestermole-gpt]

The photos that show Africa have no offset shown. The time is correct, no offset, but the wrong zone. How would I go about fixing that for the thousands of photos that imported that way?

[C-Otto]

Please have a look at #5897.

[meestermole-gpt]

the odd thing, is that this very same photo in the app on my Android tablet shows a GMT offset of -4:00 and timezone of America/Anguilla

[meestermole-gpt]

so no fix :(

[ygaeon]

Adding my old issue #9331 to here ... (no need to duplicate info, right?)

1. Not a zip-file but a link to the uploaded asset in the linked issue IMG_20240504_164142.jpg
2. 2024-05-04 16:41:42 +0200 (CET)
3. 05/04/2024, 06:41 PM (18:41) Africa/Blantyre (+02:00)

[jrasm91]

You post is quite large actually. Can you post exactly:

1. Zip file with bad asset
2. Expected day, time, + timezone
3. Current day, time, + timezone shown in immich

[ygaeon]

Updated my comment..

[jrasm91]

So this photo has no time zone information in at it all. From the exif we get:

{
  "SubSecDateTimeOriginal": "2024:06:05 00:20:20.979349",
  "DateTimeOriginal": "2024:06:05 00:20:20",
  "CreateDate": "2024:06:05 00:20:20"
}

I would expect it to:

• Show under the June 5th header in the timeline
• Display as 12:20am on June 5th in the detail panel and without a timezone

It looks like the second point isn't happening because it is displaying it using the viewer's timezone. I'll make a PR to change that.

[jrasm91]

The second point should be addressed with #12779

[ygaeon]

#9331 was just closed by @danieldietzler .
There's a lot of work going into that issue by us reporting it so please don't forget that information in that issue.

[malkavi]

Hi, I also have a lot of photos misplaced in my timeline. Those photos are old photos from external libraries.
I think the problem may be related to the lack of some metadata field (date:create and date:modify). And when importing immich modifies the files by creating those fields (??).
Maybe is my fault, I moved some folders to a new structure and lost the file creating date... Not sure. Move date can be the fake date.

Some photos from Google Takeout does not have any useful metadata.

IMG_20130913_081540.JPG:
Real date: 13/09/2013
Fake: 08/07/2024

PANO_20170416_105856.jpg:
Real date 16/April/2017
Fake date 08/July/2024

Metadata:
date:create: 2024-07-08T18:55:36+00:00
date:modify: 2024-07-08T18:55:36+00:00
exif:DateTime: 2017:04:16 10:58:56
exif:ExifOffset: 82
exif:GPSDateStamp: 2017:04:16

CameraZOOM-20150715115510237.jpg:
Real: 15/072015
Fake: 08/07/2024
Metadata:
date:create: 2024-07-08T18:54:40+00:00
date:modify: 2024-07-08T18:54:40+00:00
exif:DateTime: 2015:07:15 11:55:35

IMG_20151222_135145.vr.jpg:
Real: 22/122015
Fake: 08/07/2024
date:create: 2024-07-08T18:54:37+00:00
date:modify: 2024-07-08T18:54:37+00:00
exif:ColorSpace: 1
exif:DateTime: 2015:12:22 13:52:19
immich_malkavi_20240917.zip

[radh21301]

Hey. I think this thread is about things showing up in the wrong place when the images have metadata.

Yours is borked up because of google and has no metadata. I would try to fix that first. Some options:

• Use immich-go for takeout files. it is the one recommended by this community
• OR fix the metadata/date yourself - looks like all the names of the images have the date and time attached to it. So, you can use exiftool fort this..something like this:
  exiftool "-alldates<filename" -P ./
  Please research into exiftool before you do anything.

[chris-butterworth]

Immich v1.111.0

Hey, I am having issues with the location data.

I made the switch to immich by exporting 20k photos from Apple Photos to a directory, then imported them into Immich at a later date.

The issus is that some photos, mainly ones taking in the USA in my case, are showing up in China or the middle of the ocean.

I have found that the longitude is being calculated incorrectly, it is positive in Immich, when it should be a negative value. Flipping longitude to negative fixes location.

Original Coordinates:
Latitude: 32° 46' 59.13" N
Longitude: 96° 47' 3.6" W

Immich's Coordinates after import
Latitude: 32.78310
Longitude: 96.78433

I did search for the issue but couldn't find anyone else reporting it

[radh21301]

Hey. This thread is about timezone/timeline issues - but I suppose incorrect GPS can affect where the images shows in a timeline.
There is this post in the 'Discussions' tab, which you might not have noticed if you searched in the 'Issues'. #12224
The suggestion there was to rerun metadata extraction for this image and check of it looks okay. I uploaded your image to my server, and it shows up in Dallas, Texas - which seems to be correct. So, it does seem like whatever bug was there previously was fixed.

[D-dragon197]

Sony dslr-a550

a zip of your file: DSC09740.ZIP
the expected date, including timezone: 16 mrt 2024, 12:39 GMT+01:00
current date produced by immich: 16 mrt 2024, za 13:39 GMT+01:00

[jrasm91]

The file has a date time, but no timezone. On the latest release it shows up on the web at 12:39 and without a timezone.

"DateTimeOriginal": "2024:03:16 12:39:31",

[igor47]

i have this problem as well, shooting photos with my GRIIIx. i think the reason is that i keep any sort of GPS tagging turned off, and the photos coming out of the camera do not have time zone info. my photos make it into immich via an external library.

i would like to keep both the camera and the server in UTC and then have the photos display in the correct timezone for the users browser.

[radh21301]

Hey. Did you upgrade to the latest update? I think there is a fix for what you observe. You might not have to mess with the timezones in the server and the camera.

[igor47]

ah right you are! i attempted to refresh metadata, and it didn't seem to be working but it just took a minute -- the files are now showing up on the correct date. i will run a library-wide re-scan. thanks!

[snuq]

as requested, posting my experience over here as well.
currrently running immich 1.116

Immich displays a lot of my images and videos in the wrong date in the timeline, and in the incorrect timezone. for example:

all those photos were taken on the 10th, which immich seems to at least have an idea of internally or it wouldnt be putting them BELOW the other photos.... in previous versions, the info panel for the lower photos would say the correct date of the 10th, but now the info panel shows the 11th:

(info for the first image on the 11th)

this also happens with most videos:

(all were taken on the 29th)
and the info for the third video in the 30th folder:

My server is running in PST timezone, photos were taken in PST timezone, browser is in the PST timezone, and i have the TZ variable set in my environment variables on the server:
TZ=America/Los_Angeles

Attaching both a zip of the video:
P1299136.zip

and the image:
IMG_20230610_194503.zip

[snuq]

Upgraded to Immich 1.118.0.
Files with timezone data have improved, they are actually showing in the correct locations in the timeline.
Unfortunately, files without any exif data but correct modified and created dates are still displayed incorrectly.
both images:

and videos:

note that the file time and date for the same file are simultaneously displayed correctly in the windows explorer window on the left, but not in the immich info pane

Additionally, there is still the sorting bug in the immich timeline with these files

(ie, the videos that immich thinks are newer from the 30th should be sorted above the images from the 29th)

[C-Otto]

Did you rescan the metadata for those files?

[snuq]

I ran extract metadata on all twice

[snuq]

to provide an update: the incorrect positioning for videos without metadata (but correct file attributes) is still present in current immich (v1.120.2).
also, to clarify, there appear to be two bugs here:

1. videos without metadata but with correct modified/created dates are timestamped incorrectly (i do not know if the timzone is set in the file data and being read wrong, or if it does not have timezone data and immich is not using the local timezone as it should, but the files are listed correctly when browsing them in windows and in linux)
2. the web interface of immich is displaying the above files in the wrong order (newer files should be above older ones, but these are displayed below)

Without knowing the specifics of immich's code, i cant guess if they are the same bug or maybe just a related bug, just specifying both to be safe.

[technopaw]

I would like to add on to snuq as well. Same issue here with images that have no metadata date or time zone showing the wrong time. With these images it converts it from the correct MST to UTC. On the iPhone and Android Mobile app everything is showing correctly it is just in the web app. I have tried 3 different browsers Edge, Chrome, and safari and in incognito and not in incognito. I have also tried the mobile version of these browsers all showing the same converted date. I am on Immich version 1.121.0

[jrasm91]

If you want me to look at anything you need to do the following:

• add a zip of your file
• list the expected date, including timezone
• list current date produced by immich

[basicfu]

me too.....
1.116.0 date error
Photos without a time zone should use the set time zone, I don't understand why they are updated in reverse

[basicfu]

@C-Otto Hello, here's my question

[C-Otto]

This image does not contain any timezone information.

[basicfu]

Yes, many of my pictures do not include time zones. In previous versions, the offset was set by default, but now that the update is complete, the offset time will no longer be applied
Can a setting option be implemented to freely choose whether exif is offset from the time zone?
Or do I have any way to solve it?

[C-Otto]

@jrasm91 maybe you can chime in?

[jrasm91]

Applying an arbitrary offset is quite confusing and misleading a lot of the time. We've chosen to just show it in "local time" if there is no timezone information available. After #13262 is released this will display 1:55AM on Jan 1st, 2024 in the asset detail panel.

[bo0tzz]

This is just bad metadata, you should fix the file.

[HackerJL]

Moved a lot of photos out of Apple Photos, and kept the EXIF data intact, but a bunch of them showing up with the wrong date, but you can see the metadata right in immich, so not sure why it shows up like this.

Expected date is listed, just not sure where the first date is coming from or why immich cares about it?

[C-Otto]

The assets use the timezone offset "-05:59" in the tags that usually are used to determine the creation date. This offset is treated as an invalid offset, which is why the rest of the information is also left unused. Do you know why -05:59 is used instead of -06:00?

"SubSecCreateDate": "2017:04:02 10:26:27.763-05:59"

[HackerJL]

Oh my. That is odd. I have no clue why thats the case. Just iPhone (2 different ones). So if thats fixed up Immich is happy?

[C-Otto]

I'm pretty sure, yeah.

[HackerJL]

Worked 100%. Thank you!

[raimundmeyer]

a zip of your file

20240907_161623.zip

the expected date, including timezone

2024-09-07 16:16 (as in the filename) Timezone on the server and the browser as well as immich $TZ Europe/Berlin +02:00

current date produced by immich

date is correct, but the two hours offset of the timezone are falsely deducted

[C-Otto]

If you manually edited the metadata, you may need to delete the XMP file and refresh again. Other than that it should work (refresh metadata with v1.117.0).

[basicfu]

hello, I am currently using v1.117.0,Refreshing does not show any changes. If manually deleting. xmp and refreshing again, the following error message will appear, and the time is still incorrect

7e6c5bfee23a [Nest] 2  - 10/08/2024, 11:15:09 AM    WARN [Microservices:Error: File not found - /usr/src/app/upload/library/admin/2024/IMG_2332.PNG.xmp
7e6c5bfee23a     at ReadTask._ExifToolTask_parser (/usr/src/app/node_modules/exiftool-vendored/dist/ExifToolTask.js:76:71)
7e6c5bfee23a     at ReadTask.parser (/usr/src/app/node_modules/exiftool-vendored/dist/ExifToolTask.js:47:167)
7e6c5bfee23a     at ReadTask._Task_resolve (/usr/src/app/node_modules/batch-cluster/dist/Task.js:146:40)] Error reading exif data (upload/library/admin/2024/IMG_2332.PNG.xmp): Error: File not found - /usr/src/app/upload/library/admin/2024/IMG_2332.PNG.xmp
7e6c5bfee23a [Nest] 2  - 10/08/2024, 11:15:09 AM    WARN [Microservices:MetadataService] Asset 0895a2ba-8e90-4211-9d22-b92ad20f123d has no time zone information

[basicfu]

@C-Otto Can a setting option be implemented to freely choose whether exif is offset from the time zone?

[C-Otto]

@basicfu you are responding in @raimundmeyer's thread. My response is to him and about the photos provided in the first comment. Please open a new thread in here if you have another issue (and provide an example photo to us).

[raimundmeyer]

Refreshed metadata and looks good now. Thanks @C-Otto

[igor47]

ok, i'm now having more bizarre behavior. here's a zip with photos 1975 and 1990 served from my server since the file size exceeds github's allowed file limit: https://igor.moomers.org/random/immich-debug-photos.zip

1975 metadata:

1990 metadata:

the end result in my timeline is that 1975 is totally correct. it appears under sat sept 28 in the timeline, and what's more, it correctly appears after other photos taken with my cell phone that saturday in the evening (that is, for sat 28th i see the evening photos, then the daylight photos including 1975 as expected)

however -- 1990 appears under sunday sept 29 in my timeline. what's more -- sunday sept 29th appears later in the timeline than saturday. that is to say, when i am scrolling from the top of my timeline, i see today, yesterday, et... then sat sept 28, and then sunday sept 29 and then fri sept 27th.

immich version:

i refreshed metadata for all images taken that weekend after installing the update.

i expect to see both these photos appearing under saturday sept 28th, with 1990 appearing above 1975.

separately, i'm not sure where the timeline of africa is coming from -- my server timezone is set to UTC. i guess the UTC offset is correct but thought i would note that. in my env i have TZ="Etc/UTC" . my client is in the pacific timezone

[lgrawet]

Did you configure TZ for your server (to something other than UTC)?

@C-Otto I'm using the timezone setup from the official docker-compose.yml:

services:
  immich-server:
  ...
   volumes:
      # Do not edit the next line. If you want to change the media storage location on your system, edit the value of UPLOAD_LOCATION in the .env file
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
      - /etc/localtime:/etc/localtime:ro
  ...

On the docker host:

s -lh /etc/localtime 
lrwxrwxrwx 1 root root 35 Feb 26  2024 /etc/localtime -> /usr/share/zoneinfo/Europe/Brussels

[jrasm91]

@lgrawet can you upload a sample file, and extected vs actual expectations in a new top level comment?

[jrasm91]

@jrasm91 I don't know if this is intentional. For assets without timezone information, the time is parsed (assuming local time based on TZ) and converted to UTC when storing it in the database. In the detail pane, this time is then also shown as UTC. I believe it should be converted back to the timezone specified by TZ for displaying.

@C-Otto - Assets without timezone information should not show any timezone name/offset in the asset detail panel. The only exception I am aware of, is for videos, which always have a timezone set to UTC (probably a bug).

[C-Otto]

Which time should be shown, though? Currently, it's the local time converted to UTC (i.e. two hours off for me).

[jrasm91]

Which file?

[LittleNewton]

[mmomjian]

I agree with you in theory @alextran1502 but there is currently no good way for users to know which assets require this pre-ingest cleanup. We don't have any option such as "ignore missing timestamp" for CLI or web upload.

[jrasm91]

@LittleNewton - sure, but it's not obvious what/how to do about it and it also isn't trivial to fix either. I'm not saying we won't ever fix it, but that's the current state of things. Thank you for bringing it up and we will update this thread when we have a solution or resolution that problem.

[LittleNewton]

Hi jrasm, I have update to v1.118.1 and the time zone is still wrong. Please derive a right timezone from GPS if there is.

import pathlib
import os
import datetime

imageFolder = 'img' + '/'
File_List = os.listdir(imageFolder)


for picture in File_List:
  # get main name
  filePath = imageFolder + picture
  fileName = pathlib.Path(imageFolder + picture)
  creationTime = str(datetime.datetime.fromtimestamp(fileName.stat().st_ctime))
  baseName = ''
  for char in creationTime:
    if char != ':':
      baseName = baseName + char
  # get extension name
  newName = imageFolder + baseName + '.' + filePath.split('.')[1].lower()
  os.rename(filePath, newName)

I never use the upload functionality inside of immich because I trust my NAS's smb service more than a app and I believe there are a lot of human have the same opinion. Before I moving the photos to immich's external directory, I will use this python script to renaming them.

[LittleNewton]

This python code can derive the exact right SAVED TIME for pictures saved on your phone. The SAVED TIME is the time you save this picture from ins/x/whatsapp to your phone, not the time you press the shutter.

[jrasm91]

ctime is wrong, you can find existing issues about ctime vs mtime. The server only works if the tool that uploads the files sends the correct mtime, and so I have no idea how/where you uploaded the files, but the official cli and mobile app both correctly send this data.

[HOCHH4U5JUMP3R]

Is there any option to just disable timezones completely or shut down the date/time mess? I literally have to go through every uploaded file and either change timezone manually as it is UTC now or correct date and time completely, then see all photos again as some (shot with iPhone for example) have correct date/time, but then a screenshot for example gets UTC and is not sorted correctly with the other photos that do have Europe/Berlin. I have more than 40k assets, it's a compete mess since I had to move over from my old NAS to my new one and thought I just reupload all images/videos and sort out some old and unnecessary ones instead of just putting everything to the new NAS.
Immich Version is latest (1.123.0) coming from v1.110.0 and I have the feeling it worked way better on that old version :(

Here is one example of thousands:
It's a screenshot taken 8th of July 2020 02:59:26, it even has the date & clock on it so we can be sure it was this exact moment.
MacOS sets filenames with that timestamp, so the file is named by automation "Bildschrimfoto [Date YYYY-MM-DD] um [Time HH.MM.SS].png" in this case it is "Bildschirmfoto 2020-07-08 um 02.59.26.png"

I live in Europe/Berlin timezone this is also what I have given the .env file as TZ variable, but it seems to not matter at all.
Expectation would be: 8th of July 2020 02:59 (GMT+2:00) Europe/Berlin

This screenshot uploaded to immich results in 7th of July 2020 20:59 which is -6 hours off to the correct timestamp.
So immich has gotten the correct time of that image somewhere, and then magically decided to subtract 6 hours and set the wrong timestamp in a pseudo UTC.
It's not 6 hours off on every image, sometimes it's 8hours, I have pictures with 2 hours and 4 hours even 1 hour offsets aswell. Those are taken on the same locations too, so I'm clueless what immich does with the times at all.
But as it somehow gathers the information correctly in the first place (I assume otherwise it could not possibly guess the minutes correct each and everytime) I would like to just get rid of that magic part and use the thing it gathers initially, is that somehow possible?

Archiv.zip

[HOCHH4U5JUMP3R]

Thanks for checking, can you by chance have a look at attached file I took 2 days ago, it uploads showing 12.01.2025 19:23 UTC
Each screenshot is UTC, and the newer ones seem to be off by 1 or 2 hours depending on summer/winter time..
Screenshot from Archiv.zip was already uploaded to my old immich installation and downloaded from there, reuploaded to another immich instance with new version, might caused some trouble with the dates in the file idk...

Thank you in advance!

[luisdralves]

Sorry, I would need it zipped in order to check. Github must be doing some processing to uploaded images. However, you can also easily check for yourself. exiftool, the command I used above, has a GUI program which is simple to set up.

https://exiftool.org/gui/

[HOCHH4U5JUMP3R]

Ah I understand, I did check on my own now and here is some interesting result:

On the right is my old installation of immich (v1.110.0) on the left the new version (v1.123.0) and in the middle the exiftool with the infos. As we can see the old immich matched perfectly fine with correct date and time and timezone, the new version messed it up and changed the time 1 hour backwards (subtraction of the timezone) and made it UTC...

config files are exactly the same, even copied .env file contents to make absolutely sure.

[luisdralves]

Very interesting! It looks like there may have been a regression of some kind between those versions. We will have to wait for someone more knowledgeable to chime in.

[C-Otto]

The file does not contain any time zone offset information. Older versions of Immich assumed the configured time zone (TZ) for these assets, which is what you see on the right hand side of your screenshot. Newer versions do the same, but the implicit time zone is not shown, anymore. Instead, the TZ value is used to derive the correct "absolute" time (with time zone offset information), which then is shown as UTC (without any time zone offset information in the GUI). This way you, as a user, can see that no time zone information is available, and you're free to add it manually. See #12779

[JoshuaSeidel]

is there any actual fix for this? searching reddit and google, looks like the app not honoring the TZ has been around for over a year...

[bo0tzz]

This thread isn't a particular issue to be fixed. It's a place to collect any cases of time handling seeming off in a structured way, to avoid having a large amount of (usually wrong) individual bug reports. If you have a specific example of the handling being wrong, please post the info listed in the OP.

[dinosmm]

I'm not sure if my issue is the same as those discussed here, but...

I thought I'd fixed it by removing my external library and re-adding it one folder at a time, allowing Immich to scan the folder before adding the next one. This seemed to work, and there was no jumbling up!

However, I rebooted the server today, and the issue returned. The storage didn't come online before Immich did, which resulted in Immich showing no photos (but the database was intact, this is stored locally). I brought the storage online and restarted Immich, then I had to rescan the external library and the date headings were jumbled up again.

There doesn't seem to be an issue with reading incorrect EXIF data or anything like that. The correct date-taken is read and shown on Immich, and Immich puts the photos under the correct date heading. It's just that the headings themselves are jumbled up.

[C-Otto]

I think this is fixed in #15650 (not yet released, might end up in v1.125.3 or v1.126.0). Feel free to report back with any insights you might have!

[GITHUBNULLING]

I’m using DJI devices (Pocket 3, Action 3) to record videos, but the timestamps of the videos in Immich are incorrect. I’m in the GMT+8 timezone, but the videos are incorrectly recognized as UTC, so the time hasn’t been properly adjusted by +8 hours. However, photos taken with the DJI devices display the correct timestamps. I’m not sure whether this is an issue with the DJI device metadata or if Immich is not handling the dates properly. I’ve tested one of the devices by recording both videos and photos, packaged the files, and included screenshots showing the dates generated by Immich.


immich_timezone_mismatch.zip

[rgarcia246810]

I am having the same issue with DJI pocket 3. The way I have Immich set up is through an external library which is managed by synology photos. Long story short, the metadata is correct when viewed through synology photos, but showing up with a UTC time zone whenever viewed through immich. Therefore, I don't believe it is an issue with dji metadata. I also have videos from a gopro and those appear with a utc time zone as well. Worth noting pictures viewed on immich have the correct time zone which for me is GMT-8

[C-Otto]

For videos timezone information is extremely unrealiable, which is why all videos default to UTC. Related: photostructure/exiftool-vendored.js#113

[pingu8007]

(Referred from #15404 - it's an false alarm)

I tried to import my photo libraries into Immich and the timeline is a mess. I finally realized that my rx100m3 never wrote the timezone offset into photos even it has such configuration in the menu.

Before I messing around, I'd like to know

• can Immich drop all changes in database and reload everything from EXIF metadata? I tried to rerun the metadata tasks but nothing changed.
• can Immich modify the date/time and timezone separately? It seems Immich always save both fields, it make the batch change function hard to use.
• I found updating geo location also update the date/time and timezone, can those be unlinked? (It tried to preserve the epoch timestamp, and it's fine if the date/time is correct)

---

If all of above are no, do you think the following feature are considerable?

• add checkboxes in front of date/time and timezone and only update checked fields on save.
• add checkbox after geo location and only update date/time and timezone together if checked (checked by default).

Further more it will be great if

• add a menu item that reload everything from EXIF
• add a timezone picker in user profile that specific default timezone if not available from exif (or use browser/device timezone)

Those feature are still conceptional and open to discussion

[C-Otto]

If you run the metadata extraction job, the date is read from the file's exif tags (if they exist). Any existing XMP sidecar file takes precedence, though. If this doesn't work, your files might not contain metadata - feel free to upload examples here (zipped).

To change just the offset I wrote a small script that creates XMP files. That's not a very elegant approach, though. Short answer: no, not really possible.

Location and timezone are linked, so I don't see why these should be decoupled. If a location exists, it is used to infer timezone information. This cannot be turned off.

If you configure the TZ environment variable, this time zone is used/assumed for files that do not have any timezone metadata.

The features might be reasonable, feel free present implementation ideas!

[pingu8007]

Do you mean the timezone is determined in this order?

1. XMP sidecar
2. EXIF timestamp offset
3. EXIF geo location
4. TZ env var
5. Fallback to UTC

[C-Otto]

XMP first, yes. I'm not sure about the TZ variable, that's a topic I'll investigate soon. My current feeling is that it doesn't have any effect. The exif stuff in between is way more complicated than that, you'd need to understand lots of code both in Immich and exiftool-vendored. It depends on which values are set, how the library is configured, and the order of fields (which is also configurable). Certain time zone offsets are deemed invalid, sometimes exif tag values are implausible, ...

[thomasss02]

I have an issue with whatsapp photos.
Real date: 2025/01/19 9.56 GMT+1
Fake date 1601/01/01 01.01 GMT+1

I attach the file

[thomasss02]

[C-Otto]

Could you maybe install "Total Commander - file manager" and check the details in there? Your screenshot doesn't show a lot of information.

[thomasss02]

What kind of information do you need from this file manager?
Anywhere here Is the screenshot:

[C-Otto]

I was hoping to see something about the 1600 date, but it seems this remains a mystery.

[thomasss02]

It seems to be a browser issue

[Trainax]

Hello. I'm having some problems with timezones only on the Android app. The time and date is correct, however it's the wrong timezone.

1. Example photo in a ZIP file: IMG_20241229_123615.zip
2. Expected date, including timezone: 29/12/2024 12:36 (UTC +01:00 Europe/Rome)
3. Current date produced by immich: 29/12/2024 12:36 (UTC +01:00 Africa/Algiers)

I have set Europe/Rome as TZ inside the immich .env file. This only happens on mobile (Android in my case), on the web interface it correctly shows Europe/Rome.

Web	Mobile

Thanks!

[bo0tzz]

This is normal, we don't store the string part, it's the same timezone though.

[Trainax]

This is normal, we don't store the string part, it's the same timezone though.

Would it be possible to instead also store the string part and automatically assign the same TZ as the one set in the .env file if the time matches?

Like if the photo embedded date data says 29/12/2024 UTC +01:00 without specifying which specific timezone and the set TZ in the .env file is also a UTC +01:00 timezone then assign the timezone which is set via .env file to the photo.

Thanks again

[C-Otto]

It's not possible to store more time zone (offset) information than the numerical offset ("+01:00" etc.). However, the web page prefers the value configured in TZ if it has the same offset as the asset, which is why you see Europe/Rome instead of any of the other "+01:00" options. A similar feature might be possible for the apps.

[C-Otto]

Related: #5897

[denisjoshua]

Hi there all,
I'm new on Immich and I have just installed on a docker in my server.

Here is my date problem... I always edit the TAG using the Digikam and in base of TAG I make my albums.
But if I edit the TAG on a set of pictures using Digikam, when that pictures is refresh in Immich the pictures is on the today page.
Can this be solve in some mode please ?
Thanks
Denis

[C-Otto]

I understand that you modify the file (using another application) which then causes Immich to show these files at a different date (namely, the time of the change). If you want to fix the date, you should either include metadata in the file itself (exif), or manually edit the date once so that this information is persisted in a sidecar XMP file.

[denisjoshua]

First of all thanks for the help
What I change with another application is insert of some TAGs in the foto file... but I don't modify the "shooting date"

So after the modify (I think), Immich show me that pic under "today" menu, because the file was modified today.
And if the pic was shooting in 2016 and it show me "today" is not ok in my opinion.
Is there anything I can do please ? the unique think is to modify also the "modify" date ?

Thanks again
Denis

[C-Otto]

Immich simply doesn't detect the shooting date and falls back to the file modification date. Please provide an example file (zipped) so that we can have a look at why Immich fails to recognize the metadata.

[C-Otto]

HST is UTC-10. The photo was taken at 14:50 local time on the 22nd, which is after midnight UTC on the 23rd. It might be possible that the timeline uses UTC at this place, and from UTC's point of view the photo was taken a day before. I'll investigate.

[C-Otto]

Yes, that's the issue. The comparison confuses the local time (without any time zone information, assuming UTC) and the correct local time. This results in wrong comparison results, and wrong output ("yesterday").

[C-Otto]

web/src/lib/utils/timeline-util.ts:98

[C-Otto]

See #15634

[ckuyehar]

It's a confirmed bug; see #15634.

[danshat]

1. VID_20250211_210019.zip
2. Expected date: 11.02.2025 21:00 GMT+03:00
3. Immich date: 11.02.2025 18:00 UTC

I believe videos never have a timezone attached however Immich should fall back to default TZ then.
I have the TZ variable set in .env but Immich still does not care about it. This puts ALL of my videos three hours EARLIER in the timeline than they should be.

[DenisPac]

1. 2024-04-23 132755.zip
2. Expected date: 2024-04-23 13:27:55 GMT+4 as shown in below screenshot of exif data on Synology
   
   Note the difference between Offset Time and Offset Time Original
3. Immich date: 2024-04-23 11:27:55 GMT+2 as shown in below screenshot
   
   In .env, I have TZ=Europe/Paris
   Note: I'm using GeoSetter+EXIFtool to set the correct timezone.

[C-Otto]

This looks like photostructure/exiftool-vendored.js#220. I think this will be fixed soon, once Immich uses a more recent version of exiftool-vendored. @jrasm91 could you have a look at updating the dependency?

[Fonzi03]

OS: Docker LXC : https://community-scripts.github.io/ProxmoxVE/scripts?id=docker
Debian 12

Immich: v1.125.7

LXC date:

Container date:

I have an external library that I have a few thousand organized photos in. Most, about 75% or so are showing up with the correct date. Others however are showing up I believe based off the date they were scanned into immich.

expected date: either 01/22/24 or 02/13/24
Immich shows: 01/10/25 @2:40AM which sounds about right for when I would have gotten things running/scanning
(I tried refreshing metadata as well)

exif:

ExifTool Version Number         : 13.19
File Name                       : Blue8.png
Directory                       : A:/Photos/Jefe + Angelina Litter 2023 (Hugo)/Blue
File Size                       : 24 MB
File Modification Date/Time     : 2024:01:22 01:12:28-05:00
File Access Date/Time           : 2025:02:16 23:09:11-05:00
File Creation Date/Time         : 2024:02:13 22:44:50-05:00
File Permissions                : -rw-rw-rw-
File Type                       : PNG
File Type Extension             : png
MIME Type                       : image/png
Image Width                     : 2992
Image Height                    : 2000
Bit Depth                       : 8
Color Type                      : RGB with Alpha
Compression                     : Deflate/Inflate
Filter                          : Adaptive
Interlace                       : Noninterlaced
Profile Name                    : ICC profile
Profile CMM Type                : Little CMS
Profile Version                 : 4.3.0
Profile Class                   : Display Device Profile
Color Space Data                : RGB
Profile Connection Space        : XYZ
Profile Date Time               : 2024:01:22 06:11:03
Profile File Signature          : acsp
Primary Platform                : Microsoft Corporation
CMM Flags                       : Not Embedded, Independent
Device Manufacturer             :
Device Model                    :
Device Attributes               : Reflective, Glossy, Positive, Color
Rendering Intent                : Perceptual
Connection Space Illuminant     : 0.9642 1 0.82491
Profile Creator                 : Little CMS
Profile ID                      : 0
Profile Description             : GIMP built-in sRGB
Profile Copyright               : Public Domain
Media White Point               : 0.9642 1 0.82491
Chromatic Adaptation            : 1.04788 0.02292 -0.05022 0.02959 0.99048 -0.01707 -0.00925 0.01508 0.75168
Red Matrix Column               : 0.43604 0.22249 0.01392
Blue Matrix Column              : 0.14305 0.06061 0.71393
Green Matrix Column             : 0.38512 0.7169 0.09706
Red Tone Reproduction Curve     : (Binary data 32 bytes, use -b option to extract)
Green Tone Reproduction Curve   : (Binary data 32 bytes, use -b option to extract)
Blue Tone Reproduction Curve    : (Binary data 32 bytes, use -b option to extract)
Chromaticity Channels           : 3
Chromaticity Colorant           : Unknown
Chromaticity Channel 1          : 0.64 0.33002
Chromaticity Channel 2          : 0.3 0.60001
Chromaticity Channel 3          : 0.15001 0.06
Device Mfg Desc                 : GIMP
Device Model Desc               : sRGB
Background Color                : 255 255 255
Pixels Per Unit X               : 11811
Pixels Per Unit Y               : 11811
Pixel Units                     : meters
Modify Date                     : 2024:01:22 06:12:28
Comment                         : Created with GIMP
Image Size                      : 2992x2000
Megapixels                      : 6.0

expected date: 01/17/24
immich date: 01/10/25 @1:57AM (again potentially the time it was scanned in)

exif:

ExifTool Version Number         : 13.19
File Name                       : 7416314aa3d1454d8d45612a17b95ad6.jpg
Directory                       : A:/Photos/Holiday & Anniversary Photos/Christmas/Christmas 2023
File Size                       : 1182 kB
Zone Identifier                 : Exists
File Modification Date/Time     : 2024:01:17 20:50:33-05:00
File Access Date/Time           : 2025:02:16 23:54:45-05:00
File Creation Date/Time         : 2024:01:17 20:50:33-05:00
File Permissions                : -rw-rw-rw-
File Type                       : JPEG
File Type Extension             : jpg
MIME Type                       : image/jpeg
Profile CMM Type                : Linotronic
Profile Version                 : 2.1.0
Profile Class                   : Display Device Profile
Color Space Data                : RGB
Profile Connection Space        : XYZ
Profile Date Time               : 1998:02:09 06:49:00
Profile File Signature          : acsp
Primary Platform                : Microsoft Corporation
CMM Flags                       : Not Embedded, Independent
Device Manufacturer             : Hewlett-Packard
Device Model                    : sRGB
Device Attributes               : Reflective, Glossy, Positive, Color
Rendering Intent                : Perceptual
Connection Space Illuminant     : 0.9642 1 0.82491
Profile Creator                 : Hewlett-Packard
Profile ID                      : 0
Profile Copyright               : Copyright (c) 1998 Hewlett-Packard Company
Profile Description             : sRGB IEC61966-2.1
Media White Point               : 0.95045 1 1.08905
Media Black Point               : 0 0 0
Red Matrix Column               : 0.43607 0.22249 0.01392
Green Matrix Column             : 0.38515 0.71687 0.09708
Blue Matrix Column              : 0.14307 0.06061 0.7141
Device Mfg Desc                 : IEC http://www.iec.ch
Device Model Desc               : IEC 61966-2.1 Default RGB colour space - sRGB
Viewing Cond Desc               : Reference Viewing Condition in IEC61966-2.1
Viewing Cond Illuminant         : 19.6445 20.3718 16.8089
Viewing Cond Surround           : 3.92889 4.07439 3.36179
Viewing Cond Illuminant Type    : D50
Luminance                       : 76.03647 80 87.12462
Measurement Observer            : CIE 1931
Measurement Backing             : 0 0 0
Measurement Geometry            : Unknown
Measurement Flare               : 0.999%
Measurement Illuminant          : D65
Technology                      : Cathode Ray Tube Display
Red Tone Reproduction Curve     : (Binary data 2060 bytes, use -b option to extract)
Green Tone Reproduction Curve   : (Binary data 2060 bytes, use -b option to extract)
Blue Tone Reproduction Curve    : (Binary data 2060 bytes, use -b option to extract)
Exif Byte Order                 : Little-endian (Intel, II)
X Resolution                    : 72
Y Resolution                    : 72
Resolution Unit                 : inches
Software                        : Centrics RPS
User Comment                    : barcode:K4AJS3DR|imgKey:a01ca06850a64cceb579b1c6c206d899|OrdCnt:0|ParterID:9424
Warning                         : Invalid or extraneous ICC_Profile chunk(s)
Image Width                     : 1400
Image Height                    : 2100
Encoding Process                : Baseline DCT, Huffman coding
Bits Per Sample                 : 8
Color Components                : 3
Y Cb Cr Sub Sampling            : YCbCr4:2:0 (2 2)
Image Size                      : 1400x2100
Megapixels                      : 2.9

YAML
---
services:
  immich:
    image: ghcr.io/imagegenius/immich:latest
    container_name: immich
    environment:
      - PUID=####
      - PGID=####
      - TZ=America/New_York
      - DB_HOSTNAME=x.x.x.x
      - DB_USERNAME=####
      - DB_PASSWORD=####
      - DB_DATABASE_NAME=immich
      - REDIS_HOSTNAME=x.x.x.x
      - DB_PORT=#### #optional
      - REDIS_PORT=#### #optional
      - REDIS_PASSWORD= #### #optional
      - MACHINE_LEARNING_HOST=#### #optional
      - MACHINE_LEARNING_PORT=#### #optional
      - MACHINE_LEARNING_WORKERS=1 #optional
      - MACHINE_LEARNING_WORKER_TIMEOUT=120 #optional
    volumes:
      - /immich/config:/config
      - /FileShare/immich_uploads:/photos
      - /FileShare/Photos:/libraries #optional
    ports:
      - ####
    restart: unless-stopped
    network_mode: bridge
# This container requires an external application to be run separately.
# By default, ports for the databases are opened, be careful when deploying it
# Redis:
  redis:
    image: redis
    ports:
      - ####
    container_name: redis
    restart: unless-stopped
    network_mode: bridge
# PostgreSQL 14:
  postgres14:
    image: tensorchord/pgvecto-rs:pg14-v0.2.0
    ports:
      - ####
    container_name: postgres
    environment:
      POSTGRES_USER: ####
      POSTGRES_PASSWORD: ####
      POSTGRES_DB: immich
    volumes:
      - /immich/data:/var/lib/postgresql/data
    restart: unless-stopped
    network_mode: bridge

[Wilm0r]

edit: Huh. I tried passing a full timestamp including timezone and it seemed to not work, but after noticing that that's how the web UI does it, I tried so through the API again and yes, bingo, both got updated. Apologies for the noise!

I've been trying to fix timestamps (including timezone) on my full import using the Immich API, but I just noticed the updateAsset interface doesn't let me set the timezone, only date/time itself. :(

In the Web UI apparently both can be changed, would it be possible to add a timezone field to https://immich.app/docs/api/update-asset as well? (Or have it take the timezone portion from dateTimeOriginal? I tried to do so already but it got ignored from what I can tell.)

[mstewart14]

1. video file
2. Expected date: 2025-02-15 11:27 GMT-08:00
3. Immich date: 2025-02-15 19:27 UTC

[mstewart14]

this problem is consistent for all videos being uploaded..