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

[AFumi39]

I know all the dev team is full-time involved with the new app timeline development, but I think this is and easy fix to do:
as now every image that have no EXIF "DateTaken", is saved with DateCreated or DateModified timestamp, but with no TZ (UTC). That means that every WhatsApp o screenshot I take on the mobile, or PC, is shown with UTC time.
That's ok for the timeline sorting, but frustrating when I need to know which time the image is taken at (I have to calculate it adding the TZ difference and think if the date is DST or not).

So... Wouldn't be logic (and easy, I think) using the client or server TZ for those images? That could solve the problem with minimum effort

Thank you!

[kiyospace]

Currently immich does not get the REAL date info for original-size photos sent via SNS messengers, as DateTimeOriginal and SubSecDateTimeOriginal may be modified by messenger apps (or may be modified when downloading the photos from messenger apps). Details can be found in the discussion below. Thanks

#6459 (reply in thread)

I would suggest change the order to the following (if changing the order can solve the problem described above) and add 2 more tags (GPSDateStamp and GPSDateTime). Thanks!

 /** look for a date from these tags (in order) */ 
 const EXIF_DATE_TAGS: Array<keyof Tags> = [ 
   'SubSecCreateDate', 
   'CreationDate', 
   'CreateDate',
   'GPSDateStamp',
   'GPSDateTime',
   'SubSecMediaCreateDate', 
   'MediaCreateDate', 
   'DateTimeCreated', 
   'SubSecDateTimeOriginal', 
   'DateTimeOriginal', 
 ];

Or if the immich Date is not taking the 1st valid date value from the above array as I guessed, could someone propose something to get the REAL Date info for photos sent via SNS messengers? Thanks

[luozhlun]

1. File: DSC_4546.zip
2. Expected Date: 2024-12-24 09:06 UTC+1
3. Current Date produced by Immich: 2024-12-24 16:06 UTC+8

Device: Nikon Z72
Edited with: Lightroom

I added GPS coordinates to the photo using Lightroom, which should indicate the correct timezone (UTC+1). However, it seems Immich did not pick up the timezone from the GPS metadata and instead defaulted to my computer’s local timezone (UTC+8). Would appreciate it if this could be looked into — ideally Immich could prioritize the timezone embedded in the EXIF/XMP/IPTC metadata or inferred from GPS, rather than falling back to the system timezone.

Metadata from Exiftool

[File:System]   FileModifyDate                  : 2025:08:09 00:46:32+08:00  
[File:System]   FileAccessDate                  : 2025:08:09 01:14:34+08:00  
[File:System]   FileCreateDate                  : 2025:08:09 01:14:34+08:00  
[EXIF:IFD0]     ModifyDate                      : 2025:08:09 00:46:31  
[EXIF:ExifIFD]  DateTimeOriginal                : 2024:12:24 09:06:40  
[EXIF:ExifIFD]  CreateDate                      : 2024:12:24 09:06:40  
[EXIF:ExifIFD]  OffsetTime                      : +08:00  
[EXIF:ExifIFD]  OffsetTimeOriginal              : +01:00  
[EXIF:ExifIFD]  OffsetTimeDigitized             : +01:00  
[EXIF:ExifIFD]  SubSecTimeOriginal              : 92  
[EXIF:ExifIFD]  SubSecTimeDigitized             : 92  
[IPTC]          DateCreated                     : 2024:12:24  
[IPTC]          TimeCreated                     : 09:06:40+01:00  
[IPTC]          DigitalCreationDate             : 2024:12:24  
[IPTC]          DigitalCreationTime             : 09:06:40+01:00  
[ICC_Profile]   ProfileDateTime                 : 2015:10:14 13:08:57  
[XMP]           CreateDate                      : 2024:12:24 09:06:40.92+01:00  
[XMP]           ModifyDate                      : 2025:08:09 00:46:31+08:00  
[XMP]           MetadataDate                    : 2025:08:09 00:46:31+08:00  
[XMP]           DateCreated                     : 2024:12:24 09:06:40.92+01:00  
[XMP-MM]        HistoryWhen                     : 2025:04:19 20:57:43-05:00, 2025:08:07 22:46:46+08:00, 2025:08:09 00:46:31+08:00  
[Composite]     SubSecCreateDate                : 2024:12:24 09:06:40.92+01:00  
[Composite]     SubSecDateTimeOriginal          : 2024:12:24 09:06:40.92+01:00  
[Composite]     SubSecModifyDate                : 2025:08:09 00:46:31+08:00  
[Composite]     DateTimeCreated                 : 2024:12:24 09:06:40+01:00  
[Composite]     DigitalCreationDateTime         : 2024:12:24 09:06:40+01:00  

[majewskikarol]

Please see my new finding about incorrect creation date for edited videos in iOS - #20856

[mxmeinhold]

Currently running 1,137.3, I have some images (screenshots, other computer generated images (a panorama, a stack with a gif and the source photos)) that I was adding tags to that seem to have had the modification times reset after tagging.

I have a screenshot from 2017 that had previously been correctly sorted in my timeline, but now shows up on August 1 2024, and looking at the exif data from the file itself, I see File Modification Date/Time: 2024:08:01 01:33:14-04:00. Looking at the source image, the original creation data was 8 Dec 2017, 08:59 UTC-04:00

Looking at another screenshot from 2021 that I applied the same tag to, it looks like it has the same modification time of File Modification Date/Time: 2024:08:01 01:33:14-04:00, but also has

---- XMP-photoshop ----
Date Created: 2021:12:01 11:21:54

and is sorted correctly in the timeline

2017 screenshot with incorrect date EXIF data

Generated with exiftool -a -u -g1 -ee3 -api RequestAll=3

---- ExifTool ----
ExifTool Version Number         : 13.30
Now                             : 2025:08:11 15:42:58-04:00
New GUID                        : 20250811-1542-5800-B830-5F9E189C072A
File Sequence                   : 0
Processing Time                 : 0.0202 s
---- System ----
File Name                       : 3164a0be-dca0-491e-8e1b-d0fca808d967.JPG
Base Name                       : 3164a0be-dca0-491e-8e1b-d0fca808d967
Directory                       : /mnt/images/immich/upload/0a11c0e0-8fea-4f26-8021-cb9a2b9a1c2d/31/64
File Path                       : /mnt/images/immich/upload/0a11c0e0-8fea-4f26-8021-cb9a2b9a1c2d/31/64/3164a0be-dca0-491e-8e1b-d0fca808d967.JPG
File Size                       : 259 kB
File Modification Date/Time     : 2024:08:01 01:33:14-04:00
File Access Date/Time           : 2025:08:11 15:15:26-04:00
File Inode Change Date/Time     : 2025:01:12 19:00:20-05:00
File Permissions                : -rw-r--r--
File Attributes                 : Regular; (none)
File Device Number              : 64804
File Inode Number               : 1180882
File Hard Links                 : 1
File User ID                    : immich
File Group ID                   : immich
File Device ID                  : 0.0
File Block Size                 : 4096
File Block Count                : 512
---- File ----
File Type                       : JPEG
File Type Extension             : jpg
MIME Type                       : image/jpeg
Exif Byte Order                 : Big-endian (Motorola, MM)
Image Width                     : 1080
Image Height                    : 1920
Encoding Process                : Baseline DCT, Huffman coding
Bits Per Sample                 : 8
Color Components                : 3
Y Cb Cr Sub Sampling            : YCbCr4:2:0 (2 2)
JPEG Image Length               : 238489
JPEG Quality Estimate           : 93
JPEG Digest                     : Unknown (eb4526c2bc03499cc4cdea7544d554a8:221111)
---- JFIF ----
JFIF Version                    : 1.01
Resolution Unit                 : None
X Resolution                    : 72
Y Resolution                    : 72
---- IFD0 ----
Orientation                     : Horizontal (normal)
X Resolution                    : 72
Y Resolution                    : 72
Resolution Unit                 : inches
Y Cb Cr Positioning             : Centered
---- ExifIFD ----
Exif Version                    : 0221
Components Configuration        : Y, Cb, Cr, -
Flashpix Version                : 0100
Color Space                     : sRGB
Exif Image Width                : 1080
Exif Image Height               : 1920
Scene Capture Type              : Standard
---- IFD1 ----
Compression                     : JPEG (old-style)
X Resolution                    : 72
Y Resolution                    : 72
Resolution Unit                 : inches
Thumbnail Offset                : 316
Thumbnail Length                : 20044
Thumbnail Image                 : (Binary data 20044 bytes, use -b option to extract)
---- Composite ----
Image Size                      : 1080x1920
Megapixels                      : 2.1

2021 screenshot with correct data EXIF

Generated with exiftool -a -u -g1 -ee3 -api RequestAll=3

---- ExifTool ----
ExifTool Version Number         : 13.30
Now                             : 2025:08:11 15:43:18-04:00
New GUID                        : 20250811-1543-1800-BA90-D897AAB2D372
File Sequence                   : 0
Processing Time                 : 0.0494 s
---- System ----
File Name                       : 3183e813-5ac9-43bc-b8de-3e91e4b689bc.PNG
Base Name                       : 3183e813-5ac9-43bc-b8de-3e91e4b689bc
Directory                       : /mnt/images/immich/upload/0a11c0e0-8fea-4f26-8021-cb9a2b9a1c2d/31/83
File Path                       : /mnt/images/immich/upload/0a11c0e0-8fea-4f26-8021-cb9a2b9a1c2d/31/83/3183e813-5ac9-43bc-b8de-3e91e4b689bc.PNG
File Size                       : 1540 kB
File Modification Date/Time     : 2024:08:01 01:33:14-04:00
File Access Date/Time           : 2025:08:11 15:17:59-04:00
File Inode Change Date/Time     : 2025:01:14 11:56:15-05:00
File Permissions                : -rw-r--r--
File Attributes                 : Regular; (none)
File Device Number              : 64804
File Inode Number               : 3153773
File Hard Links                 : 1
File User ID                    : immich
File Group ID                   : immich
File Device ID                  : 0.0
File Block Size                 : 4096
File Block Count                : 3008
---- File ----
File Type                       : PNG
File Type Extension             : png
MIME Type                       : image/png
Exif Byte Order                 : Big-endian (Motorola, MM)
---- PNG ----
Image Width                     : 1170
Image Height                    : 2532
Bit Depth                       : 16
Color Type                      : RGB with Alpha
Compression                     : Deflate/Inflate
Filter                          : Adaptive
Interlace                       : Noninterlaced
Profile Name                    : kCGColorSpaceDisplayP3
---- ICC-header ----
Profile CMM Type                : Apple Computer Inc.
Profile Version                 : 4.0.0
Profile Class                   : Display Device Profile
Color Space Data                : RGB
Profile Connection Space        : XYZ
Profile Date Time               : 2017:07:07 13:22:32
Profile File Signature          : acsp
Primary Platform                : Apple Computer Inc.
CMM Flags                       : Not Embedded, Independent
Device Manufacturer             : Apple Computer Inc.
Device Model                    : 
Device Attributes               : Reflective, Glossy, Positive, Color
Rendering Intent                : Perceptual
Connection Space Illuminant     : 0.9642 1 0.82491
Profile Creator                 : Apple Computer Inc.
Profile ID                      : ca1a9582257f104d389913d5d1ea1582
---- ICC_Profile ----
Profile Description             : Display P3
Profile Copyright               : Copyright Apple Inc., 2017
Media White Point               : 0.95045 1 1.08905
Red Matrix Column               : 0.51512 0.2412 -0.00105
Green Matrix Column             : 0.29198 0.69225 0.04189
Blue Matrix Column              : 0.1571 0.06657 0.78407
Red Tone Reproduction Curve     : (Binary data 32 bytes, use -b option to extract)
Chromatic Adaptation            : 1.04788 0.02292 -0.0502 0.02959 0.99048 -0.01706 -0.00923 0.01508 0.75168
Blue 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)
---- IFD0 ----
Orientation                     : Horizontal (normal)
---- ExifIFD ----
Date/Time Original              : 2021:12:01 11:21:54
User Comment                    : Screenshot
Exif Image Width                : 1170
Exif Image Height               : 2532
---- XMP-x ----
XMP Toolkit                     : XMP Core 6.0.0
---- XMP-exif ----
User Comment                    : Screenshot
---- XMP-photoshop ----
Date Created                    : 2021:12:01 11:21:54
---- Composite ----
Image Size                      : 1170x2532
Megapixels                      : 3.0

I understand that files with limited exif data are likely to have this sort of mixup when there's new modifications, but 1. these had a correct timestamp at some point, how did those become 2024 if I'm adding tags on 11 August 2025? and 2. If immich is rewriting the modification time, could the original time have been stowed in an additional exif field, or as sidecar data?

[andreheuer]

I am also struggling with some photo uploads from iOS (see #17374 (comment)) - I have no issues with timezones, so I would not

As per my understanding, when metadata is (re-) extracted from EXIF, the tags are being used in this order:

immich/server/src/services/metadata.service.ts

Lines 36 to 50 in bbfff64

	const EXIF_DATE_TAGS: Array<keyof ImmichTags> = [
	'SubSecDateTimeOriginal',
	'SubSecCreateDate',
	'SubSecMediaCreateDate',
	'DateTimeOriginal',
	'CreateDate',
	'MediaCreateDate',
	'CreationDate',
	'DateTimeCreated',
	'GPSDateTime',
	'DateTimeUTC',
	'SonyDateTime2',
	// Undocumented, non-standard tag from insta360 in xmp.GPano namespace
	'SourceImageCreateTime' as keyof ImmichTags,
	];

The first date that was found in EXIF is then being used as relevant date for the image (or video):

immich/server/src/services/metadata.service.ts

Line 781 in bbfff64

const result = firstDateTime(exifTags);

This gives some kind of priority of one tag vs. another tag. Unfortunately, different cameras or apps are using EXIF tags sometimes differently. So depending on the device or app you are using, the relevant EXIF tag might be a different one and different dates might be stored in the tags.

So my suggestions would be instead of using the first found date in these tags (in this method), to use the oldest date (respecting timezones / offsets etc.) found in all those EXIF tags. Most likely, this will be the date where the file was created / and or the picture was taken (or at least close by).

Would that be a potential way forward (as an idea)?

EDIT: I have issues with .mov files imported from iOS and recorded via iOS

[kiyospace]

Thanks for the proposal. Using the oldest date found in all EXIF_DATE_TAGS would work the problem I am having, which is some SNS messengers may modify the DateTimeOriginal to my download time from the messenger apps - although the photos are sent as "original photos".

Also, there needs some judgement to make sure the oldest date found among the tags is reasonable - not sure some camera device would have 1970-00-00 or 1900-00-00 or such filled automatically if some DateTime fields are actually "empty".

[chemicalsam]

Running 1.138.0. Screenshots that are taken and uploaded on iOS get the wrong timezone/date and are subsequently in the wrong order on the timeline.

Timezone should be New York but isn’t. It also seems that when a photo is saved from Messages. It assigns it the wrong time and date. It uses the date that it was saved instead of the original metadata shown in Photos.

[kittychi]

My immich server has TZ set to America/Vancouver. I use external libraries to import photos from my camera that I organize in folders into immich. I have two photos that were taken back to back that have a 7hr difference when imported to immich.

DSCN3987.zip This shows up at the correct time in immich.

DSCN3988.zip This shows up 7hrs later in immich.

I expect both to show up as 14:40 UTC-7.
Location data was added through immich.

[JarodSch]

zip file (of one effected file) is attached. All of the effected files are .mov like that
20150714_083723.mov.zip

time it should have is 2015-07-14 08:37:26+02:00
time it has in Immich: 2021-12-08 02:37+02:00

ExifTool Version Number         : 13.30
File Name                       : 20150714_083723.mov
Directory                       : .
File Size                       : 11 MB
File Modification Date/Time     : 2025:08:20 15:04:14+02:00
File Access Date/Time           : 2025:08:20 15:04:17+02:00
File Inode Change Date/Time     : 2025:08:20 15:15:39+02:00
File Permissions                : -rw-r--r--
File Type                       : MOV
File Type Extension             : mov
MIME Type                       : video/quicktime
Major Brand                     : Apple QuickTime (.MOV/QT)
Minor Version                   : 0.0.0
Compatible Brands               : qt
Media Data Size                 : 11403327
Media Data Offset               : 36
Movie Header Version            : 0
Create Date                     : 2021:12:08 00:37:52
Modify Date                     : 2021:12:08 00:37:52
Time Scale                      : 600
Duration                        : 2.00 s
Preferred Rate                  : 1
Preferred Volume                : 100.00%
Preview Time                    : 0 s
Preview Duration                : 0 s
Poster Time                     : 0 s
Selection Time                  : 0 s
Selection Duration              : 0 s
Current Time                    : 0 s
Next Track ID                   : 3
Track Header Version            : 0
Track Create Date               : 2021:12:08 00:37:52
Track Modify Date               : 2021:12:08 00:37:52
Track ID                        : 1
Track Duration                  : 2.00 s
Track Layer                     : 0
Track Volume                    : 0.00%
Image Width                     : 3840
Image Height                    : 2160
Clean Aperture Dimensions       : 3840x2160
Production Aperture Dimensions  : 3840x2160
Encoded Pixels Dimensions       : 3840x2160
Graphics Mode                   : ditherCopy
Op Color                        : 32768 32768 32768
Compressor ID                   : avc1
Source Image Width              : 3840
Source Image Height             : 2160
X Resolution                    : 72
Y Resolution                    : 72
Compressor Name                 : 'avc1'
Bit Depth                       : 24
Video Frame Rate                : 28.014
Matrix Structure                : 1 0 0 0 1 0 0 0 1
Media Header Version            : 0
Media Create Date               : 2021:12:08 00:37:52
Media Modify Date               : 2021:12:08 00:37:52
Media Time Scale                : 48000
Media Duration                  : 2.05 s
Media Language Code             : und
Balance                         : 0
Handler Class                   : Data Handler
Handler Vendor ID               : Apple
Handler Description             : Core Media Data Handler
Audio Format                    : mp4a
Audio Channels                  : 2
Audio Bits Per Sample           : 16
Audio Sample Rate               : 48000
Purchase File Format            : mp4a
Handler Type                    : Metadata Tags
Creation Date                   : 2015:07:14 08:37:26+02:00
Image Size                      : 3840x2160
Megapixels                      : 8.3
Avg Bitrate                     : 45.7 Mbps
Rotation                        : 0

[andbgr]

someone posted above from the source code:

immich/server/src/services/metadata.service.ts

Lines 35 to 50 in bbfff64

	/** look for a date from these tags (in order) */
	const EXIF_DATE_TAGS: Array<keyof ImmichTags> = [
	'SubSecDateTimeOriginal',
	'SubSecCreateDate',
	'SubSecMediaCreateDate',
	'DateTimeOriginal',
	'CreateDate',
	'MediaCreateDate',
	'CreationDate',
	'DateTimeCreated',
	'GPSDateTime',
	'DateTimeUTC',
	'SonyDateTime2',
	// Undocumented, non-standard tag from insta360 in xmp.GPano namespace
	'SourceImageCreateTime' as keyof ImmichTags,
	];

CreateDate and MediaCreateDate seem to have higher priority than CreationDate, and are also present in your file, so your wrong date is coming from CreateDate (i think that's "Kodierungsdatum")

a quick fix would be to change CreateDate to match CreationDate

or maybe CreationDate should have higher priority, from what i understand it is a quicktime specific tag, i'm not sure if that means it is always 'more right' than CreateDate when present, maybe someone with more experience can tell us that

[andbgr]

Weird one, i even have a fix, but i don't understand it:

expected date:
see screenshot after

date displayed:
see screenshot before

zip:
1975 07 caM Porträts u DKW C-09 F-08 008.zip

before:

$ exiftool '1975 07 caM Porträts u DKW C-09 F-08 008.JPG' | grep Date
File Modification Date/Time     : 2025:06:04 02:20:57+02:00
File Access Date/Time           : 2025:08:22 14:02:45+02:00
File Inode Change Date/Time     : 2025:08:22 14:02:34+02:00
Modify Date                     : 2022:08:03 08:04:59
Date/Time Original              : 1975:07:01 00:00:00
Create Date                     : 
Metadata Date                   : 2022:08:03 08:04:59+02:00
Profile Date Time               : 1999:06:03 00:00:00
Date/Time Original              : 1975:07:01 00:00:00.019

the fix:
i noticed that there is a CreateDate consisting of 19 whitespaces. took me a while to figure that out. if i fix it, the timezone goes away. however, while all of the images in this batch had this malformed CreateDate, only half of them had the timezone issue, which is also how i noticed it, because they were in the wrong order. so maybe the fix did something else at the same time?

exiftool -if '$CreateDate eq " "' -CreateDate="" .

after:

$ exiftool '1975 07 caM Porträts u DKW C-09 F-08 008.JPG' | grep Date
File Modification Date/Time     : 2025:08:22 14:08:34+02:00
File Access Date/Time           : 2025:08:22 14:08:34+02:00
File Inode Change Date/Time     : 2025:08:22 14:08:34+02:00
Modify Date                     : 2022:08:03 08:04:59
Date/Time Original              : 1975:07:01 00:00:00
Metadata Date                   : 2022:08:03 08:04:59+02:00
Profile Date Time               : 1999:06:03 00:00:00
Date/Time Original              : 1975:07:01 00:00:00.019

EDIT:
i just learned the whitespaces are conforming to standard (from https://www.cipa.jp/std/documents/download_e.html?DC-008-Translation-2023-E), so my "fix" is not something i'm supposed to do...

The format is "YYYY:MM:DD HH:MM:SS" with time shown in 24-hour format, and the date and time separated by one blank character [20.H]. When the date and time are unknown, all the character spaces except colons (":") should be filled with blank characters, or else the field should be filled with blank characters.

[andbgr]

UPDATE:

first, some more tags that were masked by duplicates:

$ exiftool -a -g -s 1975\ 07\ caM\ Porträts\ u\ DKW\ C-09\ F-08\ 008.JPG | grep -i '\(----\|date\|time\)' | grep -v File
---- ExifTool ----
---- EXIF ----
ModifyDate                      : 2022:08:03 08:04:59
DateTimeOriginal                : 1975:07:01 00:00:00
CreateDate                      : 
SubSecTimeOriginal              : 019
---- IPTC ----
---- Photoshop ----
---- XMP ----
CreateDate                      : 2022:07:26 09:30:04+02:00
MetadataDate                    : 2022:08:03 08:04:59+02:00
ModifyDate                      : 2022:08:03 08:04:59+02:00
---- ICC_Profile ----
ProfileDateTime                 : 1999:06:03 00:00:00
---- APP14 ----
---- Composite ----
SubSecDateTimeOriginal          : 1975:07:01 00:00:00.019

now, a new "fix":

exiftool -xmp:CreateDate="2022:07:26 09:30:04+03:00" 1975\ 07\ caM\ Porträts\ u\ DKW\ C-09\ F-08\ 008.JPG

the result:

interpretation:

Immich seems to take the Date/Time from Exif:DateTimeOriginal and combine it with the Offset (only the offset) from xmp:CreateDate, which is a different date, and can therefore have a different timezone.
The presence of an empty Exif:CreateDate seems to be coincidental (deleting it made no difference).

-> i think this is a bug (i made a bug report but was asked to post here, so i updated this post instead)

[nanoBit93]

Hey,
I have an issue with photos uploaded from my iCloud Photo Library from my iPhone. Most pictures have the correct date, but a few hundred don't. Not exactly sure though if the issue is Immich or Apple. I've downloaded it via Immich web and sent it to my Mac via Airdrop for comparison. When I send it over Airdrop the correct date is in the EXIF data. Interestingly though, none of the pictures has the location that iCloud is able to read.

File in Immich:

exiftool 2.JPG
ExifTool Version Number : 13.34
File Name : 2.JPG
Directory : .
File Size : 3.3 MB
File Modification Date/Time : 2024:10:02 02:15:58+02:00
File Access Date/Time : 2025:08:26 00:34:23+02:00
File Inode Change Date/Time : 2025:08:26 00:34:20+02:00
File Permissions : -rw-r--r--
File Type : JPEG
File Type Extension : jpg
MIME Type : image/jpeg
JFIF Version : 1.01
Exif Byte Order : Big-endian (Motorola, MM)
X Resolution : 72
Y Resolution : 72
Resolution Unit : inches
Color Space : sRGB
Exif Image Width : 3600
Exif Image Height : 2700
Current IPTC Digest : d41d8cd98f00b204e9800998ecf8427e
IPTC Digest : d41d8cd98f00b204e9800998ecf8427e
Image Width : 3600
Image Height : 2700
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 : 3600x2700
Megapixels : 9.7

Airdropped File:

exiftool 2_airdrop.JPG
ExifTool Version Number : 13.34
File Name : 2_airdrop.JPG
Directory : .
File Size : 2.9 MB
File Modification Date/Time : 2015:08:01 09:20:16+02:00
File Access Date/Time : 2025:08:26 00:35:48+02:00
File Inode Change Date/Time : 2025:08:26 00:35:47+02:00
File Permissions : -rw-r--r--
File Type : JPEG
File Type Extension : jpg
MIME Type : image/jpeg
JFIF Version : 1.01
Exif Byte Order : Big-endian (Motorola, MM)
X Resolution : 72
Y Resolution : 72
Resolution Unit : inches
Color Space : sRGB
Exif Image Width : 3600
Exif Image Height : 2700
XMP Toolkit : XMP Core 6.0.0
Artwork Content Description :
Image Width : 3600
Image Height : 2700
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 : 3600x2700
Megapixels : 9.7

[andbgr]

you did not mention what date immich shows.
however, from what you posted (assuming the exiftool output is complete) there seems to be no date information in the metadata in either file, the File Modification/Access/Inode Change Dates are just the timestamps of the files in the filesystem, which can change for any number of reasons (like downloading them).
When Immich finds no date in the metadata, it falls back on the file timestamps.

[zen-pavel]

All my assets have correct time in Immich, but wrong Time zones (original is +03:00) in several cases:

Videos are usually fine in the web, but in an app (iOS) they all have phone time zone.
Expected: 2021:10:10 14:50 +03:00
Web: 2021:10:10 14:50 +03:00
App: 2021:10:10 19:50 +08:00
20211010_145035.zip

Video metadata

---- File ----
File Name                       : 20211010_145035.mp4
Directory                       : .
File Size                       : 13 MB
File Modification Date/Time     : 2025:08:30 22:28:01+08:00
File Access Date/Time           : 2025:08:31 16:32:29+08:00
File Creation Date/Time         : 2025:08:29 18:58:32+08:00
File Permissions                : -rw-rw-rw-
File Type                       : MP4
File Type Extension             : mp4
MIME Type                       : video/mp4
---- QuickTime ----
Major Brand                     : MP4 v2 [ISO 14496-14]
Minor Version                   : 0.0.0
Compatible Brands               : isom*mp42
Movie Header Version            : 0
Create Date                     : 2021:10:10 11:50:41
Modify Date                     : 2021:10:10 11:50:41
Time Scale                      : 10000
Duration                        : 4.57 s
Preferred Rate                  : 1
Preferred Volume                : 100.00%
Matrix Structure                : 1 0 0 0 1 0 0 0 1
Preview Time                    : 0 s
Preview Duration                : 0 s
Poster Time                     : 0 s
Selection Time                  : 0 s
Selection Duration              : 0 s
Current Time                    : 0 s
Next Track ID                   : 3
Play Mode                       : SEQ_PLAY
Handler Type                    : Metadata Tags
Android Version                 : 11
Android Capture FPS             : 60
Track Header Version            : 0
Track Create Date               : 2021:10:10 11:50:41
Track Modify Date               : 2021:10:10 11:50:41
Track ID                        : 1
Track Duration                  : 4.57 s
Track Layer                     : 0
Track Volume                    : 0.00%
Matrix Structure                : 0 1 0 -1 0 0 0 0 1
Image Width                     : 1920
Image Height                    : 1080
Media Header Version            : 0
Media Create Date               : 2021:10:10 11:50:41
Media Modify Date               : 2021:10:10 11:50:41
Media Time Scale                : 90000
Media Duration                  : 4.57 s
Handler Type                    : Video Track
Handler Description             : VideoHandle
Graphics Mode                   : srcCopy
Op Color                        : 0 0 0
Compressor ID                   : avc1
Source Image Width              : 1920
Source Image Height             : 1080
X Resolution                    : 72
Y Resolution                    : 72
Bit Depth                       : 24
Pixel Aspect Ratio              : 65536:65536
Color Profiles                  : nclx
Color Primaries                 : BT.709
Transfer Characteristics        : BT.709
Matrix Coefficients             : BT.709
Video Full Range Flag           : Limited
Video Frame Rate                : 60.01
Track Header Version            : 0
Track Create Date               : 2021:10:10 11:50:41
Track Modify Date               : 2021:10:10 11:50:41
Track ID                        : 2
Track Duration                  : 4.54 s
Track Layer                     : 0
Track Volume                    : 100.00%
Matrix Structure                : 1 0 0 0 1 0 0 0 1
Media Header Version            : 0
Media Create Date               : 2021:10:10 11:50:41
Media Modify Date               : 2021:10:10 11:50:41
Media Time Scale                : 48000
Media Duration                  : 4.54 s
Handler Type                    : Audio Track
Handler Description             : SoundHandle
Balance                         : 0
Audio Format                    : mp4a
Audio Channels                  : 2
Audio Bits Per Sample           : 16
Audio Sample Rate               : 48000
Media Data Size                 : 12990988
Media Data Offset               : 10161
---- XMP ----
XMP Toolkit                     : Image::ExifTool 13.33
Location Created GPS Latitude   : 55.613086° N
Location Created GPS Longitude  : 37.682488° E
Creator                         : Лена
Subject                         : 2021*2021|1010 Осень в Царицыно
Date/Time Original              : 2021:10:10 14:50:41+03:00
GPS Latitude                    : 55.613086° N
GPS Longitude                   : 37.682488° E
GPS Date/Time                   : 2025:08:30 14:23:56+00:00
Hierarchical Subject            : 2021*2021|1010 Осень в Царицыно
Date Created                    : 2021:10:10 14:50:41+03:00
Artist                          : Лена
Create Date                     : 2021:10:10 14:50:41+03:00
Creator Tool                    : photools.com IMatch 25.5.0.1 (Windows)
Metadata Date                   : 2025:08:30 22:28:01+08:00
Modify Date                     : 2025:08:30 22:28:01+08:00
Artist                          : Лена
Document ID                     : xmp.did:e5586d05-dbc1-44d7-89dc-8aac11df2002
Instance ID                     : xmp.iid:acdd4ba3-1be6-441f-9581-3635b74bea46
Original Document ID            : xmp.did:e5586d05-dbc1-44d7-89dc-8aac11df2002
---- Composite ----
Image Size                      : 1920x1080
Megapixels                      : 2.1
Avg Bitrate                     : 22.8 Mbps
Rotation                        : 90
GPS Latitude Ref                : North
GPS Longitude Ref               : East
GPS Position                    : 55.613086° N, 37.682488° E

Photos have server time zone in the web and phone time in the mobile app.
Expected: 2021:10:10 14:50 +03:00
Web: 2021:10:10 19:50 +08:00
App: 2021:10:10 19:50 +08:00
20211010_145015.zip

Photo metadata

---- File ----
File Name                       : 20211010_145015.jpg
Directory                       : .
File Size                       : 5.2 MB
File Modification Date/Time     : 2025:08:30 22:27:57+08:00
File Access Date/Time           : 2025:08:31 16:32:29+08:00
File Creation Date/Time         : 2025:08:29 19:01:54+08:00
File Permissions                : -rw-rw-rw-
File Type                       : JPEG
File Type Extension             : jpg
MIME Type                       : image/jpeg
Exif Byte Order                 : Little-endian (Intel, II)
Image Width                     : 4032
Image Height                    : 3024
Encoding Process                : Baseline DCT, Huffman coding
Bits Per Sample                 : 8
Color Components                : 3
Y Cb Cr Sub Sampling            : YCbCr4:2:0 (2 2)
---- EXIF ----
Make                            : samsung
Camera Model Name               : SM-G991B
Orientation                     : Rotate 90 CW
X Resolution                    : 72
Y Resolution                    : 72
Resolution Unit                 : inches
Software                        : G991BXXU3AUIE
Modify Date                     : 2025:08:30 22:27:57
Artist                          : Лена
Y Cb Cr Positioning             : Centered
Exposure Time                   : 1/1684
F Number                        : 1.8
Exposure Program                : Program AE
ISO                             : 50
Exif Version                    : 0220
Date/Time Original              : 2021:10:10 14:50:15
Create Date                     : 2021:10:10 14:50:15
Offset Time                     : +08:00
Offset Time Original            : +03:00
Offset Time Digitized           : +03:00
Components Configuration        : Y, Cb, Cr, -
Shutter Speed Value             : 1/1675
Aperture Value                  : 1.8
Brightness Value                : 8.31
Exposure Compensation           : 0
Max Aperture Value              : 1.8
Metering Mode                   : Center-weighted average
Flash                           : No Flash
Focal Length                    : 5.4 mm
User Comment                    : 
Sub Sec Time Original           : 0775
Sub Sec Time Digitized          : 0775
Flashpix Version                : 0100
Color Space                     : sRGB
Exif Image Width                : 4032
Exif Image Height               : 3024
Interoperability Index          : R98 - DCF basic file (sRGB)
Interoperability Version        : 0100
Scene Type                      : Unknown (.)
Custom Rendered                 : Normal
Exposure Mode                   : Auto
White Balance                   : Auto
Digital Zoom Ratio              : undef
Focal Length In 35mm Format     : 26 mm
Scene Capture Type              : Standard
Contrast                        : Normal
Saturation                      : Normal
Sharpness                       : Normal
Image Unique ID                 : R12LLMF05VM
GPS Version ID                  : 2.3.0.0
GPS Latitude Ref                : North
GPS Latitude                    : 55.613086°
GPS Longitude Ref               : East
GPS Longitude                   : 37.682488°
GPS Time Stamp                  : 14:23:56
GPS Date Stamp                  : 2025:08:30
Image Width                     : 512
Image Height                    : 384
Compression                     : JPEG (old-style)
Orientation                     : Rotate 90 CW
X Resolution                    : 72
Y Resolution                    : 72
Resolution Unit                 : inches
Thumbnail Offset                : 1212
Thumbnail Length                : 35618
Thumbnail Image                 : (Binary data 35618 bytes, use -b option to extract)
---- XMP ----
XMP Toolkit                     : Image::ExifTool 13.33
Digital Image GUID              : R12LLMF05VM
Location Created GPS Latitude   : 55.613086° N
Location Created GPS Longitude  : 37.682488° E
Creator                         : Лена
Subject                         : 2021*2021|1010 Осень в Царицыно
Aperture Value                  : 1.8
Brightness Value                : 8.31
Color Space                     : sRGB
Components Configuration        : Y*Cb*Cr*-
Contrast                        : Normal
Custom Rendered                 : Normal
Date/Time Digitized             : 2021:10:10 14:50:15.0775+03:00
Date/Time Original              : 2021:10:10 14:50:15.0775+03:00
Digital Zoom Ratio              : undef
Exif Version                    : 0220
Exposure Compensation           : 0
Exposure Mode                   : Auto
Exposure Program                : Program AE
Exposure Time                   : 1/1684
F Number                        : 1.8
Flash Fired                     : False
Flash Function                  : False
Flash Mode                      : Unknown
Flash Red Eye Mode              : False
Flash Return                    : No return detection
Flashpix Version                : 0100
Focal Length                    : 5.4 mm
Focal Length In 35mm Format     : 26 mm
GPS Latitude                    : 55.613086° N
GPS Longitude                   : 37.682488° E
GPS Date/Time                   : 2025:08:30 14:23:56Z
GPS Version ID                  : 2.3.0.0
ISO                             : 50
Image Unique ID                 : R12LLMF05VM
Max Aperture Value              : 1.8
Metering Mode                   : Center-weighted average
Exif Image Width                : 4032
Exif Image Height               : 3024
Saturation                      : Normal
Scene Capture Type              : Standard
Sharpness                       : Normal
Shutter Speed Value             : 1/1675
User Comment                    : 
White Balance                   : Auto
Image Unique ID                 : R12LLMF05VM
Interoperability Index          : R98 - DCF basic file (sRGB)
Photographic Sensitivity        : 50
Hierarchical Subject            : 2021*2021|1010 Осень в Царицыно
Date Created                    : 2021:10:10 14:50:15.0775+03:00
Artist                          : Лена
Compression                     : JPEG (old-style)
Image Height                    : 384
Image Width                     : 512
Make                            : samsung
Camera Model Name               : SM-G991B
Orientation                     : Rotate 90 CW
Resolution Unit                 : inches
Software                        : G991BXXU3AUIE
X Resolution                    : 72
Y Cb Cr Positioning             : Centered
Y Resolution                    : 72
Create Date                     : 2021:10:10 14:50:15.0775+03:00
Creator Tool                    : G991BXXU3AUIE
Metadata Date                   : 2025:08:30 22:27:57+08:00
Modify Date                     : 2025:08:30 22:27:57+08:00
Artist                          : Лена
Document ID                     : xmp.did:c2ceb871-43b1-44b3-8079-c3662849d885
Instance ID                     : xmp.iid:21da8d56-9a9c-44e4-b9a5-dbc288f15ffa
Original Document ID            : xmp.did:c2ceb871-43b1-44b3-8079-c3662849d885
---- MakerNotes ----
Time Stamp                      : 2021:10:10 19:50:15.842+08:00
MCC Data                        : Russian Federation (250)
---- Composite ----
Aperture                        : 1.8
Image Size                      : 4032x3024
Megapixels                      : 12.2
Scale Factor To 35 mm Equivalent: 4.8
Shutter Speed                   : 1/1684
Create Date                     : 2021:10:10 14:50:15.0775+03:00
Date/Time Original              : 2021:10:10 14:50:15.0775+03:00
Modify Date                     : 2025:08:30 22:27:57+08:00
GPS Date/Time                   : 2025:08:30 14:23:56Z
GPS Latitude                    : 55.613086° N
GPS Longitude                   : 37.682488° E
Flash                           : No Flash
GPS Latitude Ref                : North
GPS Longitude Ref               : East
Circle Of Confusion             : 0.006 mm
Field Of View                   : 69.4 deg
Focal Length                    : 5.4 mm (35 mm equivalent: 26.0 mm)
GPS Position                    : 55.613086° N, 37.682488° E
Hyperfocal Distance             : 2.60 m
Light Value                     : 13.4

[andbgr]

i had a look only at the photo:
i confirmed through experiment that Immich seems to combine DateTimeOriginal with OffsetTime (which is +08:00) instead of OffsetTimeOriginal (which is +03:00).

from https://www.cipa.jp/std/documents/download_e.html?DC-008-Translation-2023-E:

OffsetTime
A tag used to record the offset from UTC (the time difference from Universal Time Coordinated including daylight saving time) of the time of DateTime tag.
[...]
OffsetTimeOriginal
A tag used to record the offset from UTC (the time difference from Universal Time Coordinated including daylight saving time) of the time of DateTimeOriginal tag.

-> maybe someone can confirm this but i think this is a bug

[zen-pavel]

Your assumption seems correct for the web, but doesn't explain phone time zone in the iOS app.

[HelloMihai]

I found a SOLUTION for my video cases

note:

using example times

issue:

locally on my Mac Apps correct time and zone displayed: 11:19am
in immich it was displaying with the wrong offset 6:19 am GMT-4:00

good vs bad videos:

checking the differences between video files that worked and ones that were wrong I found a missing metadata tag

[QuickTime:Keys] CreationDate                   : 2025:08:27 11:19:00-03:00

make sure you have the right offset at the end eg: -03:00

solution

(assuming -3 timezone delta for you)
adding this tag fixed it the discrepancy for me
SO... first tag is for immich & second tag is for local on your computer

exiftool -overwrite_original \
  -QuickTime:CreateDate="2025:08:27 15:06:00" \
  -Keys:CreationDate="2025:08:27 12:06:00-03:00" \
  video.mov

other things to try

check your docker containers date is correct (assuming immich_server is your docker container name)

docker exec -it immich_server bash
root@ba0aa8aa8370:/usr/src/app# date
Wed Sep  3 07:13:50 XXX 2025
root@ba0aa8aa8370:/usr/src/app# 

make sure XXX is the correct timezone. If its wrong, check your servers timezone config, and check that its properly set in your docker container.

[andbgr]

i think i found a real issue:

Immich combines dates/times with timezones/offsets from different tags that are not supposed to go together

in #12650 (comment), DateTimeOriginal is combined with the offset from CreateDate

in #12650 (comment), DateTimeOriginal is combined with OffsetTime which is also the wrong combination (see my reply)

Unless someone points out a flaw in my reasoning i will go ahead an make a bug report

EDIT:
someone already made a bug report for the OffsetTime issue, so i made another one for the CreateDate one

[magnusbjarnason]

Posting here based on advice given in different thread for different issue, pointing to this thread for ALL date/time related issues.

Running immich v1.140.1 in a docker container on an ubuntu 22.04 desktop distro.

Images are:

1. Hosted on a NAS
2. Mounted on the ubuntu server from using fstab as read-only
3. Defined in docker.compose.yml "/opt/docker/immich/external/my-photos:/external/my-photos:ro" as read-only
4. Loaded into immich as an external library

My issue is that a lot of my images are being shown on their file-modified date, instead of creation date, in the example below they are shown on Today's date 2025:09:08, instead of when they were taken/modified [DateTimeOriginal] = [ModifyDate] = 2016:05:15 10:48:56.

[ExifTool] ExifToolVersion : 13.34
[File] FileName : 13234713_10206612912545726_1882212518_o_26967680691_o.jpg
[File] Directory : /volume1/homes/USER/Photos/FOLDER/SUBFOLDER
[File] FileSize : 556 kB
[File] FileModifyDate : 2025:09:08 14:20:11+02:00
[File] FileAccessDate : 2025:09:08 14:20:14+02:00
[File] FileInodeChangeDate : 2025:09:08 14:20:11+02:00
[File] FilePermissions : -rwxrwxrwx
[File] FileType : JPEG
[File] FileTypeExtension : jpg
[File] MIMEType : image/jpeg
[File] ExifByteOrder : Little-endian (Intel, II)
[File] CurrentIPTCDigest : 99b8ba27ac7953f040d98955345a515d
[File] ImageWidth : 1332
[File] ImageHeight : 1776
[File] EncodingProcess : Progressive DCT, Huffman coding
[File] BitsPerSample : 8
[File] ColorComponents : 3
[File] YCbCrSubSampling : YCbCr4:2:0 (2 2)
[JFIF] JFIFVersion : 1.02
[JFIF] ResolutionUnit : None
[JFIF] XResolution : 1
[JFIF] YResolution : 1
[EXIF] ModifyDate : 2016:05:15 10:48:56
[EXIF] DateTimeOriginal : 2016:05:15 10:48:56
[ICC_Profile] ProfileCMMType :
[ICC_Profile] ProfileVersion : 2.0.0
[ICC_Profile] ProfileClass : Display Device Profile
[ICC_Profile] ColorSpaceData : RGB
[ICC_Profile] ProfileConnectionSpace : XYZ
[ICC_Profile] ProfileDateTime : 2009:03:27 21:36:31
[ICC_Profile] ProfileFileSignature : acsp
[ICC_Profile] PrimaryPlatform : Unknown ()
[ICC_Profile] CMMFlags : Not Embedded, Independent
[ICC_Profile] DeviceManufacturer :
[ICC_Profile] DeviceModel :
[ICC_Profile] DeviceAttributes : Reflective, Glossy, Positive, Color
[ICC_Profile] RenderingIntent : Perceptual
[ICC_Profile] ConnectionSpaceIlluminant : 0.9642 1 0.82491
[ICC_Profile] ProfileCreator :
[ICC_Profile] ProfileID : 29f83ddeaff255ae7842fae4ca83390d
[ICC_Profile] ProfileDescription : sRGB IEC61966-2-1 black scaled
[ICC_Profile] BlueMatrixColumn : 0.14307 0.06061 0.7141
[ICC_Profile] BlueTRC : (Binary data 2060 bytes, use -b option to extract)
[ICC_Profile] DeviceModelDesc : IEC 61966-2-1 Default RGB Colour Space - sRGB
[ICC_Profile] GreenMatrixColumn : 0.38515 0.71687 0.09708
[ICC_Profile] GreenTRC : (Binary data 2060 bytes, use -b option to extract)
[ICC_Profile] Luminance : 0 80 0
[ICC_Profile] MeasurementObserver : CIE 1931
[ICC_Profile] MeasurementBacking : 0 0 0
[ICC_Profile] MeasurementGeometry : Unknown
[ICC_Profile] MeasurementFlare : 0%
[ICC_Profile] MeasurementIlluminant : D65
[ICC_Profile] MediaBlackPoint : 0.01205 0.0125 0.01031
[ICC_Profile] RedMatrixColumn : 0.43607 0.22249 0.01392
[ICC_Profile] RedTRC : (Binary data 2060 bytes, use -b option to extract)
[ICC_Profile] Technology : Cathode Ray Tube Display
[ICC_Profile] ViewingCondDesc : Reference Viewing Condition in IEC 61966-2-1
[ICC_Profile] MediaWhitePoint : 0.9642 1 0.82491
[ICC_Profile] ProfileCopyright : Copyright International Color Consortium, 2009
[ICC_Profile] ChromaticAdaptation : 1.04791 0.02293 -0.0502 0.0296 0.99046 -0.01707 -0.00925 0.01506 0.75179
[IPTC] SpecialInstructions : FBMD01000a840d0000e28d0000f7a101009cb0010018c80100e614030066f204000a0e0500bb2905008e4c0500887c0800
[Composite] ImageSize : 1332x1776
[Composite] Megapixels : 2.4

This seemingly affects everything I change, as when I tried writing DateTimeOriginal tag to a large batch of photos at once, to make sure they had the proper and same EXIF tag, they all moved to todays date in Immich, after I did a complete refresh of all my image metadata.

I can replicate it easily, by editing photo dates using Synology Photos for example, which sets DateTimeOriginal + Modifydate to what I state it should be - but of course also changes the FileModifyDate tag to todays date + time. When going into Immich, photo is shown on "today".

Attachment:
13234713_10206612912545726_1882212518_o_26967680691_o.zip

[Ricostyle21]

I seem to have exactly the same issue with a lot of my assets. Extracting metadata briefly fixes the sorting in the timeline, and very quickly after that another job moves them back to their modification date places in the timeline, messing everything up again. If you (of anyone else) has a fix for this, I'd be happy to hear about it. If anyone needs more information/metadata, let me know and I'll post that.

[riccardoruspoli]

The new v1.141.1 update should fix this issue. Be sure to update to the latest version on both the server and mobile, delete the affected assets from the server, and try to upload them again, with metadata extraction.

[magnusbjarnason]

I just tried updating and while indeed, many photos were moved to correct, dates, some still remain on the wrong dates.

Example:

[ExifTool] ExifToolVersion : 13.34
[File] FileName : img_20160328_135932_01_26064407946_o.jpg
[File] Directory : /volume1/homes/username/Photos/Albums/foldername
[File] FileSize : 204 kB
[File] FileModifyDate : 2025:09:09 10:32:43+02:00
[File] FileAccessDate : 2025:09:09 10:32:49+02:00
[File] FileInodeChangeDate : 2025:09:09 10:32:43+02:00
[File] FilePermissions : -rwxrwxrwx
[File] FileType : JPEG
[File] FileTypeExtension : jpg
[File] MIMEType : image/jpeg
[File] ExifByteOrder : Big-endian (Motorola, MM)
[File] ImageWidth : 768
[File] ImageHeight : 1024
[File] EncodingProcess : Baseline DCT, Huffman coding
[File] BitsPerSample : 8
[File] ColorComponents : 3
[File] YCbCrSubSampling : YCbCr4:2:0 (2 2)
[JFIF] JFIFVersion : 1.01
[JFIF] ResolutionUnit : None
[JFIF] XResolution : 72
[JFIF] YResolution : 72
[EXIF] ModifyDate : 2016:03:28 13:36:27
[EXIF] DateTimeOriginal : 2016:03:28 13:36:27
[EXIF] ColorSpace : sRGB
[EXIF] ExifImageWidth : 768
[EXIF] ExifImageHeight : 1024
[Photoshop] IPTCDigest : d41d8cd98f00b204e9800998ecf8427e
[Composite] ImageSize : 768x1024
[Composite] Megapixels : 0.786

Attached:
img_20160328_135932_01_26064407946_o.zip

Notes:
My images are not stored on the server where Immich runs:

1. Hosted on a NAS
2. Mounted on the ubuntu server from using fstab as read-only
3. Defined in docker.compose.yml "/opt/docker/immich/external/my-photos:/external/my-photos:ro" as read-only
4. Loaded into immich as an external library

Hence I cannot perform " delete the affected assets from the server, and try to upload them again, with metadata extraction.".
I did re-scan the external library and exctract all metadata over again, however this did not make any difference unfortunately.