[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.

[ATFieldBeast]

the sample pic

2358720_20240821222543_1.zip

the expected date, including timezone

2024-08-21 22:25:45 UTC+08:00
(I am in the UTC+08:00 timezone, but this pic is a screenshot which doesn't have any exif)

current date produced by immich

2024-08-21 22:25:45 inside the container ✅
2024-08-21 22:25:45 on the iOS app ✅
2024-08-21 14:25:45 on the webui ❌

@bo0tzz says I should post here, so I post my issue here again as #23058

time for images without EXIF showing 8 hours earlier on the webui

I have already added /etc/localtime and even /etc/timezone in the Docker Compose configuration, and set the environment variable TZ=Asia/Shanghai (UTC+08:00)
The system time and container time are both correct, and when checking the image information used exiftool inside the container, it is also correct, and showed no time data related to 14:25
However, in the webui, the time displayed for such screenshots without EXIF is 8 hours earlier than the real time (the linux system which run immich and the windows system which browser the webui are both set on UTC+08:00). You can see the timestamp from the filename (e.g., Steam timestamp) as evidence

But in the mobile app, the time displayed is correct. This makes me think that the time stored in the database might be correct, and there could be an issue when the webui retrieves or converts the time

Actually, this issue has persisted since version after 1.115. I had been using version 1.115 all along, which version both webui and app are showing correct time
But recently the mobile app updated to version 2.1.0, which no longer allows connecting to older server versions. So I set up a new 2.1.0 service for testing and found that this problem still exists

Is this a bug, or is there some configuration I haven't found yet?

[eddified]

This looks like it might be the same bug I mentioned in the previous comment.

Note that the datetimes appear correct in mobile apps because mobile apps don’t use the server’s version of the time (another comment in this thread seems to make this point well).

My personal opinion is that the datetimes of images without EXIF data are wrong in the server’s db.

[ATFieldBeast]

This looks like it might be the same bug I mentioned in the previous comment.

Note that the datetimes appear correct in mobile apps because mobile apps don’t use the server’s version of the time (another comment in this thread seems to make this point well).

My personal opinion is that the datetimes of images without EXIF data are wrong in the server’s db.

So you mean that the reason could be that the database is indeed storing the wrong time, and the fact that the iOS app displays it correctly is precisely because of another error or feature? OMG, that's just...😂

[ATFieldBeast]

This looks like it might be the same bug I mentioned in the previous comment.

Note that the datetimes appear correct in mobile apps because mobile apps don’t use the server’s version of the time (another comment in this thread seems to make this point well).

My personal opinion is that the datetimes of images without EXIF data are wrong in the server’s db.

hi, bro, after the system ran the scheduled backup task, I noticed another thing. My backup settings haven't been changed from the default, which is 02:00 (2 AM). Judging from the resulting filenames, the timestamp in them is also 0200. However, the actual execution time was 10:00, meaning it ran 8 hours later than scheduled. It seems there's still something off with the timezone configuration

[SkyLordJay]

This looks like it might be the same bug I mentioned in the previous comment.

Note that the datetimes appear correct in mobile apps because mobile apps don’t use the server’s version of the time (another comment in this thread seems to make this point well).

My personal opinion is that the datetimes of images without EXIF data are wrong in the server’s db.

I agree with this! The photos that I've saved from other apps like Instagram have no metadata, so I would expect them to use the timestamp shown in IOS (dated created/modified whatever), and it does, except in the web view the time is off by four hours. I'm in eastern time so that would make sense. I have my .env timezone set to 'America/New_York' The Immich mobile app shows the correct timestamp if the original is still on my device, but if I delete the original from my device, the Immich app then adds four hours to the timestamp, presumably using the server's database timestamp which is incorrect. All of my other photos that have proper metadata are showing the correct timestamp.

[SkyLordJay]

I've mentioned this in my issue #23383 but since I suppose it was a duplicate (my bad) it was closed, but I feel like this might be important to this issue, so I wanted to add this bit to the discussion, so that it can maybe help move along this problem.

I noticed that the API for the asset/get (getAssetInfo) endpoint has this to say about fileCreatedAt

"The actual UTC timestamp when the file was created/captured, preserving timezone information. This is the authoritative timestamp for chronological sorting within timeline groups. Combined with timezone data, this can be used to determine the exact moment the photo was taken."

But when I requested the asset info myself using http://localhost:2283/api/assets/8c224d1d-913f-41fc-9619-3b6627074629?apiKey=<key> the fileCreatedAt field read this 2025-10-27T20:45:56.000Z which does not preserve the time zone despite what the API docs say, and since this asset doesn't have EXIF metadata, there's no way to figure out which time locale it was taken at. This wouldn't necessarily be an issue assuming the web view formats it according to the browsers locale as stated in the settings

"Format dates and numbers based on your browser locale"

But that does not appear to be happening for these assets that lack EXIF metadata

[waltericewhite]

I uploaded seperate zip files since github has a limit of 25mb per file.
photo 1 which has this issue.JPG.zip Date Time Original: 17 Jun 2025 at 11:03:13 IST(UTC+5:30)
photo 2 which has this issue.NEF.zip Date Time Original: 16 Jun 2025 at 23:11:11 IST(UTC+5:30)
video file which has this issue.MOV.zip Date Time Original: 16 Jun 2025 at 23:11:11 IST(UTC+5:30)

I have some photos and videos, when on device everything shows completely good, I also tested with examing raw metadata with various tools, also uploaded to google photos, apple photos, ente photos and they show the correct metadata. Even the immich mobile app shows the correct metadata when on device section. Once I upload it, they mess up the data and everything is messed up, the same photos and videos shows different time and timezone on web ui and mobile app, I tried uploading from mobile app, web ui, everything no luck.

uploaded my docker-compose and env files. I have set my TZ to Asia/Kolkata and server is properly synced. Everything is properly setup.
stack.env.txt
docker-compose.yml

It's been a lot of year since this issue arised and immich is perfect and I think this is the only part that needs correction. Thank you for your work!

[dengke80622]

Unraid docker, immich server version 2.2.3
I use photosync to backup my photos.
No location for both HEIC and MOV file and they are not linked as live photo even they have same identifier ID.

[ascmove]

hello, when do you fix this bug?

[epicjourney-dev]

I understand why open source maintainers burns out. You could use some kindness, since this is not a service you're paying. And even if you paid it, that's not the right way.

[JarodSch]

When you develop a fix and push it.

[ascmove]

The field 'fileCreateTime' got from filesys fs.stat api, which is a syscall, in a linux terminal, this create time shown as 'Modify: 2025-03-21 19:52:13.000000000 +0400', and its saved time as '2025-03-21T13:52:13.000Z', so server modele works well.
The problem is in web module, field 'fileCreatedAt' got from backend is '2025-03-21T13:52:13.000Z', is a standard ISO-8601 format as UTC+0 timezone, but my local computer timezone is UTC+4, the FE does not convert time to localtime.

[Artyom-K]

A photo sent to me has exif fields with proper data but for some reason immich uses FileModifyDate which is the date the file was actually sent to me via Telegram. The file is in the external library.
Immich shows 05:10:09 30.08.2025
I need 18:31:02 18.07.2025
Here is the output of exiftool -s -g1 -time:all for this file.

---- System ----
FileModifyDate                  : 2025:08:30 10:10:09+05:00
FileAccessDate                  : 2025:10:21 14:22:52+05:00
FileCreateDate                  : 2025:10:21 14:22:52+05:00
---- IFD0 ----
ModifyDate                      : 2025:07:18 18:31:02
---- ExifIFD ----
SubSecTimeDigitized             : 531
SubSecTimeOriginal              : 531
SubSecTime                      : 531
CreateDate                      : 2025:07:18 18:31:02
DateTimeOriginal                : 2025:07:18 18:31:02
---- Composite ----
SubSecCreateDate                : 2025:07:18 18:31:02.531
SubSecDateTimeOriginal          : 2025:07:18 18:31:02.531
SubSecModifyDate                : 2025:07:18 18:31:02.531

IMG_20250718_183102.zip

[daFreeMan]

Here's my contribution. This is one of several our daughter sent us via WhatsApp shortly after having taken them, so the WA time stamp should be within a few minutes of the time stamp on the actual image on her phone - I'm not worried if their off by a few minutes, but they're off by a couple of months!

IMG-20250729-WA0017.zip

Date/Time as shown by Immich:

I note that every time zone comes up as (+00:00) on every image I have when I look at in browser. However, I just looked at this same image on my phone (Google Pixel 8) and the TZ is -4 which is correct for my current location, but not where the picture was taken.

Actual Date:

2025-07-29 12:36 + 0100 (GMT+2) EDIT: (corrected from GMT+1)

-- Note minutes are approximate - that's when I received it via WhatsApp - if that's the closest you can extract, I'm 100% great with that. Her phone (or WhatsApp) doesn't seem to include a time stamp in the filename.

[AIDANMSIMONS]

I've been grappling for some time with Immich showing the wrong timezone on photos taken on a DSLR set to GMT in Kenya (GMT+03:00) with the GPS location added from a trackfile. I thought I had it sussed by using exiftool to set the timezone but, while exiftool reported TimeZone="+03:00" Immich was displaying "GMT+04:00".

Tried several times to change the timezone in exiftool and Extract Metadata in Immich, to no avail.

When I asked exiftool for -time:all I realised there's a Daylight Savings option (Yes/No) which was set to Yes. That would explain the discrepancy...

Might be helpful to someone else in the same boat.

Is it possible to Extract Metadata for a subset of files? (I'm using External Libraries and it take quite a while to rescan the whole lot when I'm resolving individual folders).

[Geweldich]

I've been using Immich for awhile now and yesterday on the eve of the big planned family Immich migration I noticed a discrepancy between the time/date shown in the web interface (correct) vs the Android app (one hour in the future). :(

As requested a test photo:
immich_test.zip

The expected date+time:
20251208 (YYYYMMDD), 08:46 CET

Before uploading to the server the phone shows 08:46

After uploading/syncing to the server the web interface shows 08:46

After uploading to the server the phone shows 09:46

I hope you guys can tell me what's wrong. I use Immich on my TrueNAS. The time in the docker container is correct:

$ date
Mon Dec  8 09:03:05 CET 2025

The Immich TZ variable is set to Europe/Amsterdam. My phone is in the same timezone (shows as GMT +01:00 in the Android settings)

[fizbin]

For the record, with the file in this zip:

$ exiftool -args -time:all IMG_20251208_084624.jpg 
-FileModifyDate=2025:12:08 07:50:36+00:00
-FileAccessDate=2025:12:08 21:40:51+00:00
-FileInodeChangeDate=2025:12:08 21:40:46+00:00
-ModifyDate=2025:12:08 08:46:26
-SubSecTimeDigitized=148
-SubSecTimeOriginal=148
-SubSecTime=148
-CreateDate=2025:12:08 08:46:26
-DateTimeOriginal=2025:12:08 08:46:26
-SubSecCreateDate=2025:12:08 08:46:26.148
-SubSecDateTimeOriginal=2025:12:08 08:46:26.148
-SubSecModifyDate=2025:12:08 08:46:26.148

[Geweldich]

For the record, with the file in this zip:

$ exiftool -args -time:all IMG_20251208_084624.jpg 
-FileModifyDate=2025:12:08 07:50:36+00:00
-FileAccessDate=2025:12:08 21:40:51+00:00
-FileInodeChangeDate=2025:12:08 21:40:46+00:00
-ModifyDate=2025:12:08 08:46:26
-SubSecTimeDigitized=148
-SubSecTimeOriginal=148
-SubSecTime=148
-CreateDate=2025:12:08 08:46:26
-DateTimeOriginal=2025:12:08 08:46:26
-SubSecCreateDate=2025:12:08 08:46:26.148
-SubSecDateTimeOriginal=2025:12:08 08:46:26.148
-SubSecModifyDate=2025:12:08 08:46:26.148

Hi, is this helpful info for the devs, or were you trying to inform me of something? I have absolutely no clue what's going on here/why Immich is behaving like this. I've never seen this behavior with the evil cloud services I've been using before.

[fizbin]

I have written a rough tool that people hit with this issue might find useful: https://github.com/fizbin/immich-tz-fixer

It changes the timezone on immich assets to match a given timezone, and can also reset the second and sub-second parts of an asset's time if you have the original file and that file has within it fine-grained time metadata. It is not a tool I want to make easily available yet, but if you're comfortable with the command line and git use, if you're posting in this thread you may find this tool useful.

Please do not use the tool without using the --dry-run option once first.

[JamesZBL]

IMG_Immich_Date_Wrong.zip

Expected：2025-12-09 18:54
Real：2025-12-10 02:54

⸻

Immich iOS 2.3.0
Immich Server 2.3.1
Both set to the Asia/Shanghai (UTC+8) timezone.

A screenshot taken on iOS at 6:00 PM on January 1st gets backed up to Immich and appears as 2:00 AM on January 2nd, showing an 8-hour difference.

Other Android devices on the same LAN don’t have this issue.

[devogabs]

Environment

• Immich version: v2.4.1
• Deployment method: Docker Compose
• OS / Host: Fedora Workstation 43
• Storage: External HDD mounted at /mnt/sda3
• Browser / Client: Web + Android app
• Timezone (host): America/Sao_Paulo
• Timezone (Immich): default ?

Summary

After migrating from Google Photos (Google Takeout), a large portion of my photos
are assigned to a single incorrect date (e.g. 2025-12-23), despite having correct
timestamps either in the filename, Google JSON metadata, or corrected EXIF.

What I tried

• Downloaded Google Takeout (photos + JSON sidecars)
• Extracted files locally
• Ran scripts to fix EXIF dates before import
• Re-imported into Immich
• Deleted and re-imported affected assets

Result

• Some photos are correctly dated
• Many screenshots / WhatsApp / Twitter images are grouped under a single day
• Re-importing causes a large number of assets to be treated as "new" instead of duplicates

Example:

example.zip

asset's EXIF:

ExifTool Version Number : 13.10
File Name : 20201229_084055.jpg
Directory : .
File Size : 78 kB
File Modification Date/Time : 2025:12:29 13:13:50-03:00
File Access Date/Time : 2025:12:29 13:14:54-03:00
File Inode Change Date/Time : 2025:12:29 13:13:51-03:00
File Permissions : -rw-r--r--
File Type : JPEG
File Type Extension : jpg
MIME Type : image/jpeg
JFIF Version : 1.01
Exif Byte Order : Little-endian (Intel, II)
Software : Picasa
Exif Version : 0220
Color Space : sRGB
Exif Image Width : 1065
Exif Image Height : 1017
Interoperability Index : R98 - DCF basic file (sRGB)
Interoperability Version : 0100
Image Unique ID : 82a63bf084b090350000000000000000
Compression : JPEG (old-style)
X Resolution : 72
Y Resolution : 72
Resolution Unit : inches
Thumbnail Offset : 324
Thumbnail Length : 6778
Image Width : 1065
Image Height : 1017
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 : 1065x1017
Megapixels : 1.1
Thumbnail Image : (Binary data 6778 bytes, use -b option to extract)

This may be related to import-time date resolution and/or deduplication behaviour.
I’m opening a separate issue with a detailed reproduction case.

[alextran1502]

You should use immich-go to upload google takeouts to Immich as it handles writing the metadata to the file correctly https://github.com/simulot/immich-go

[alextran1502]

Many screenshots / WhatsApp / Twitter images are grouped under a single day

This is expected as they don't have correct EXIF on creation

[azaricstefan]

I used immich-go, since it was failing I rerun in multiple times. I got same problem, multiple images imported with wrong dates and they got duplicated.

[corsac-s]

IMG_2315.zip

Here's a file from an older Canon camera (EOS 350D) with no timezone information:

exiftool -time:all IMG_2315.JPG 
File Modification Date/Time     : 2025:12:30 21:52:47+01:00
File Access Date/Time           : 2025:12:30 21:52:48+01:00
File Inode Change Date/Time     : 2025:12:30 21:52:47+01:00
Modify Date                     : 2025:12:30 21:51:15
Date/Time Original              : 2025:12:30 21:51:15
Create Date                     : 2025:12:30 21:51:15

Immich doesn't display any timezone information (which I guess is correct) but sorts it in the timeline as if it was 21:51:15Z, so before another file (IMG_5785.zip).

That second file has timezone information (UTC+1):

exiftool -time:all IMG_5785.JPG
File Modification Date/Time     : 2025:12:30 21:59:42+01:00
File Access Date/Time           : 2025:12:30 22:00:12+01:00
File Inode Change Date/Time     : 2025:12:30 21:59:46+01:00
Modify Date                     : 2025:12:30 21:56:12
Date/Time Original              : 2025:12:30 21:56:12
Create Date                     : 2025:12:30 21:56:12
Offset Time                     : +01:00
Offset Time Original            : +01:00
Offset Time Digitized           : +01:00
Sub Sec Time Original           : 823
Sub Sec Time Digitized          : 823
GPS Time Stamp                  : 20:56:06
GPS Date Stamp                  : 2025:12:30
Profile Date Time               : 2022:01:01 00:00:00
Create Date                     : 2025:12:30 21:56:12.823+01:00
Date/Time Original              : 2025:12:30 21:56:12.823+01:00
Modify Date                     : 2025:12:30 21:56:12+01:00
GPS Date/Time                   : 2025:12:30 20:56:06Z

So the issue here is that Immich seems to treat timezone absence as UTC+00. A correct behavior would be to use the locally configured timezone (from .env) which in my case is Europe/Paris (so UTC+1 at the moment, UTC+2 in the summer).

The file are both from an external library, so maybe the default timezone could also be a library attribute but I'm not sure that's a thing.

[richadams]

I'm having exactly the same issue, but this wasn't always the case. Immich used to use the local timezone when there was no timezone information in the file, but recently the behavior seems to have changed to force UTC instead in that scenario.

[ascmove]

Hi, allThis bug has been fixed in version 2.4.1在 2026年1月3日，12:04，Rich Adams ***@***.***> 写道： I'm having exactly the same issue, but this wasn't always the case. Immich used to use the local timezone when there was no timezone information in the file, but recently the behavior seems to have changed to force UTC instead in that scenario. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[corsac-s]

I'm not exactly sure if you're replying to my bug or not (the threading doesn't show it but the quote seems to indicate it). The bug is present in 2.4.1 for me.