immich-app/immich
1
0
Fork 0
mirror of https://github.com/immich-app/immich.git synced 2026-02-05 00:30:57 +03:00
Code Issues 11 Packages Projects Releases 10 Wiki Activity

[BUG] Wrong Date but Exif good #1653

New Issue
Closed
opened 2026-02-05 02:52:21 +03:00 by OVERLORD · 27 comments
OVERLORD commented 2026-02-05 02:52:21 +03:00
Owner
Copy Link

Originally created by @stevenwalton on GitHub (Nov 20, 2023).

The bug

I was testing a way to backup my Google Photos and though, hey, I'll try to move some photos to the device and see if Immich automatically syncs them. Not a great solution because you can't batch move images to device but that's not important.

So I test with a few images, taking my oldest images. As expected Immich backs up the photo. Success? These photos are actually at the newest portion of my timeline. So I go to today's Immich folder and run exiftool myimg.jpg. Looking at the output things look right

$ /path/immich_library/library/admin/2023/2023-11-19 $ exiftool 2012041619xxxx+1.jpg | grep -i date
File Modification Date/Time     : 2023:11:19 13:xx:xx-08:00
File Access Date/Time           : 2023:11:19 14:xx:xx-08:00
File Inode Change Date/Time     : 2023:11:19 14:xx:xx-08:00
Modify Date                     : 2012:04:16 19:xx:xx
...

In this case we can probably tell which is the correct date given the name of the file but probably not something to rely on. x's artificial because you don't need minute and second the photo was taken. The other exif data is also good but irrelevant to the topic at hand (it correctly captures the phone I used, software that processed the image, etc).

I believe that Immich is grabbing the most up to date time rather than the actual date the photo was taken (in 2012). In the web interface we also see that it says the photo was taken at Nov 19, 2023Sun, 9:36 PM GMT which does not seem to match any time I'm seeing.

I don't know much about the internals to this software so I don't know if just changing the key it looks for resolves this issue or breaks others but just that this is unexpected behavior. I apologize if someone else has brought up the issue but I couldn't find it.

The OS that Immich Server is running on

Debian 12 (bookworm) on a raspberry pi 4

Version of Immich Server

v1.86.0

Version of Immich Mobile App

v1.87.9 build.111

Platform with the issue

  • Server
  • Web
  • Mobile

Your docker-compose.yml content

Standard with the 3 lines for hardware acceleration commented out

Your .env content

Standard

Edit

I didn't check hard enough. Some images did get properly moved to the correct location on the timeline! Here's the same output for images that DID move correctly

endurance@endurance:/epool/immich_library/library/admin/2014/2014-01-14 $ exiftool 20140114_09xxxx+1.jpg | grep -i date
File Modification Date/Time     : 2023:11:19 13:xx:xx-08:00
File Access Date/Time           : 2023:11:19 15:xx:xx-08:00
File Inode Change Date/Time     : 2023:11:19 13:xx:xx-08:00
Modify Date                     : 2014:01:14 09:xx:xx
Date/Time Original              : 2014:01:14 09:xx:xx
Create Date                     : 2014:01:14 09:xx:xx

It appears their exif data is slightly different. The systematic pattern is that the files that did not move correctly were taken with the "Pudding camera" app, which looks to generate slightly different data. Those photos were also taken from a Droid 2 but the correct photos form a Galaxy S3.

Originally created by @stevenwalton on GitHub (Nov 20, 2023). ### The bug I was testing a way to backup my Google Photos and though, hey, I'll try to move some photos to the device and see if Immich automatically syncs them. Not a great solution because you can't batch move images to device but that's not important. So I test with a few images, taking my oldest images. As expected Immich backs up the photo. Success? These photos are actually at the newest portion of my timeline. So I go to today's Immich folder and run `exiftool myimg.jpg`. Looking at the output things look right ``` $ /path/immich_library/library/admin/2023/2023-11-19 $ exiftool 2012041619xxxx+1.jpg | grep -i date File Modification Date/Time : 2023:11:19 13:xx:xx-08:00 File Access Date/Time : 2023:11:19 14:xx:xx-08:00 File Inode Change Date/Time : 2023:11:19 14:xx:xx-08:00 Modify Date : 2012:04:16 19:xx:xx ... ``` In this case we can probably tell which is the correct date given the name of the file but probably not something to rely on. x's artificial because you don't need minute and second the photo was taken. The other exif data is also good but irrelevant to the topic at hand (it correctly captures the phone I used, software that processed the image, etc). I believe that Immich is grabbing the most up to date time rather than the actual date the photo was taken (in 2012). In the web interface we also see that it says the photo was taken at `Nov 19, 2023Sun, 9:36 PM GMT` which does not seem to match any time I'm seeing. I don't know much about the internals to this software so I don't know if just changing the key it looks for resolves this issue or breaks others but just that this is unexpected behavior. I apologize if someone else has brought up the issue but I couldn't find it. ### The OS that Immich Server is running on Debian 12 (bookworm) on a raspberry pi 4 ### Version of Immich Server v1.86.0 ### Version of Immich Mobile App v1.87.9 build.111 ### Platform with the issue - [X] Server - [ ] Web - [X] Mobile ### Your docker-compose.yml content Standard with the 3 lines for hardware acceleration commented out ### Your .env content Standard # Edit I didn't check hard enough. Some images did get properly moved to the correct location on the timeline! Here's the same output for images that ***DID*** move correctly ``` endurance@endurance:/epool/immich_library/library/admin/2014/2014-01-14 $ exiftool 20140114_09xxxx+1.jpg | grep -i date File Modification Date/Time : 2023:11:19 13:xx:xx-08:00 File Access Date/Time : 2023:11:19 15:xx:xx-08:00 File Inode Change Date/Time : 2023:11:19 13:xx:xx-08:00 Modify Date : 2014:01:14 09:xx:xx Date/Time Original : 2014:01:14 09:xx:xx Create Date : 2014:01:14 09:xx:xx ``` It appears their exif data is slightly different. The systematic pattern is that the files that did not move correctly were taken with the "Pudding camera" app, which looks to generate slightly different data. Those photos were also taken from a Droid 2 but the correct photos form a Galaxy S3.
OVERLORD commented 2026-02-05 02:52:27 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Nov 20, 2023):

Are all the jobs finished yet? especially the extract metadata job?

@alextran1502 commented on GitHub (Nov 20, 2023): Are all the jobs finished yet? especially the extract metadata job?
OVERLORD commented 2026-02-05 02:52:30 +03:00
Author
Owner
Copy Link

@stevenwalton commented on GitHub (Nov 20, 2023):

Wow, impressive response time! (Thanks for the project too!)

I believe so but we can give it an hour to check and I can also reboot the container.

Looking at my logs I see a bunch of lines such as

immich_microservices       | [Nest] 7  - 11/19/2023, 10:xx:xx PM     LOG [MediaService] Successfully generated WEBP video thumbnail for asset 4be68fbc-4931-408f-959a-4251e32e4fc3

Further up there are errors like this

immich_microservices       | [Nest] 7  - 11/19/2023, 9:xx:xx PM   ERROR [StorageTemplateService] Error: Connection terminated due to connection timeout
immich_microservices       |     at Connection.<anonymous> (/usr/src/app/node_modules/pg/lib/client.js:132:73)
immich_microservices       |     at Object.onceWrapper (node:events:628:28)
immich_microservices       |     at Connection.emit (node:events:514:28)
immich_microservices       |     at Socket.<anonymous> (/usr/src/app/node_modules/pg/lib/connection.js:63:12)
immich_microservices       |     at Socket.emit (node:events:514:28)
immich_microservices       |     at TCP.<anonymous> (node:net:337:12)
immich_microservices       | [Nest] 7  - 11/19/2023, 9:xx:xx PM   ERROR [StorageTemplateService] Object:
immich_microservices       | {
immich_microservices       |   "id": "efc899e2-debc-447d-a72a-081fda2d074a",
immich_microservices       |   "oldPath": "upload/upload/bf823dda-38c1-472f-971e-f74cd0ba3e75/13340531-fa92-4b0b-a64e-4402330ab2a6.jpg",
immich_microservices       |   "newPath": "upload/library/admin/2014/2014-01-14/20140114_11xxxx+1.jpg"
immich_microservices       | }
immich_microservices       |

But these are for the images that actually got placed in the correct location. I also have some errors about the ML jobs erroring out but I'm not too worried about those. I can get them if you want (it's only classified two faces and two images. Server's been up for over a week but initial upload of images had the ML container shut down).

I grepped for the year because exact date couldn't find anything and there was too much looking by hand

endurance@endurance:~/immich $ docker-compose logs --follow | grep "2012"
...
immich_microservices       | [Nest] 7  - 11/19/2023, 10:01:07 PM     LOG [StorageCore] Attempting to finish incomplete move: upload/upload/bf823dda-38c1-472f-971e-f74cd0ba3e75/f40f67cc-d98c-41ad-9780-efbd85e19a35.jpg => upload/library/admin/2023/2023-11-19/2012041619xxxx.jpg

This is the only message that is associated with the previous image. There are only two of these messages and others have errors, here's an example. From the above command, they all have this same form

immich_microservices       | [Nest] 7  - 11/16/2023, 12:01:07 AM   ERROR [JobService] Unable to run job handler (thumbnailGeneration/generate-webp-thumbnail): Error: Input file is missing: upload/library/admin/2022/2022-12-13/Screenshot_20221213-20xxxxng
immich_microservices       | [Nest] 7  - 11/16/2023, 12:01:07 AM   ERROR [JobService] Error: Input file is missing: upload/library/admin/2022/2022-12-13/Screenshot_20221213-20xxxx.png
immich_microservices       | [Nest] 7  - 11/16/2023, 12:01:07 AM   ERROR [JobService] Unable to run job handler (thumbnailGeneration/generate-webp-thumbnail): Error: Input file is missing: upload/library/admin/2022/2022-12-13/Screenshot_20221213-20xxxx.png

It's only two files actually and both have leading "Screenshot" but there are 9 instances of the error. This is all I see grepping for the 2012 year.

Clearly my server's clock is incorrect so ignore the other time issue above about being 9pm.

Edit: guess the classifier is processing these images since it is updating (but also not important here)

@stevenwalton commented on GitHub (Nov 20, 2023): Wow, impressive response time! (Thanks for the project too!) I believe so but we can give it an hour to check and I can also reboot the container. Looking at my logs I see a bunch of lines such as ``` immich_microservices | [Nest] 7 - 11/19/2023, 10:xx:xx PM LOG [MediaService] Successfully generated WEBP video thumbnail for asset 4be68fbc-4931-408f-959a-4251e32e4fc3 ``` Further up there are errors like this ```immich_microservices | [Nest] 7 - 11/19/2023, 9:xx:xx PM ERROR [StorageTemplateService] Problem applying storage template immich_microservices | [Nest] 7 - 11/19/2023, 9:xx:xx PM ERROR [StorageTemplateService] Error: Connection terminated due to connection timeout immich_microservices | at Connection.<anonymous> (/usr/src/app/node_modules/pg/lib/client.js:132:73) immich_microservices | at Object.onceWrapper (node:events:628:28) immich_microservices | at Connection.emit (node:events:514:28) immich_microservices | at Socket.<anonymous> (/usr/src/app/node_modules/pg/lib/connection.js:63:12) immich_microservices | at Socket.emit (node:events:514:28) immich_microservices | at TCP.<anonymous> (node:net:337:12) immich_microservices | [Nest] 7 - 11/19/2023, 9:xx:xx PM ERROR [StorageTemplateService] Object: immich_microservices | { immich_microservices | "id": "efc899e2-debc-447d-a72a-081fda2d074a", immich_microservices | "oldPath": "upload/upload/bf823dda-38c1-472f-971e-f74cd0ba3e75/13340531-fa92-4b0b-a64e-4402330ab2a6.jpg", immich_microservices | "newPath": "upload/library/admin/2014/2014-01-14/20140114_11xxxx+1.jpg" immich_microservices | } immich_microservices | ``` But these are for the images that actually got placed in the correct location. I also have some errors about the ML jobs erroring out but I'm not too worried about those. I can get them if you want (it's only classified two faces and two images. Server's been up for over a week but initial upload of images had the ML container shut down). I grepped for the year because exact date couldn't find anything and there was too much looking by hand ``` endurance@endurance:~/immich $ docker-compose logs --follow | grep "2012" ... immich_microservices | [Nest] 7 - 11/19/2023, 10:01:07 PM LOG [StorageCore] Attempting to finish incomplete move: upload/upload/bf823dda-38c1-472f-971e-f74cd0ba3e75/f40f67cc-d98c-41ad-9780-efbd85e19a35.jpg => upload/library/admin/2023/2023-11-19/2012041619xxxx.jpg ``` This is the only message that is associated with the previous image. There are only two of these messages and others have errors, here's an example. From the above command, they all have this same form ``` immich_microservices | [Nest] 7 - 11/16/2023, 12:01:07 AM ERROR [JobService] Unable to run job handler (thumbnailGeneration/generate-webp-thumbnail): Error: Input file is missing: upload/library/admin/2022/2022-12-13/Screenshot_20221213-20xxxxng immich_microservices | [Nest] 7 - 11/16/2023, 12:01:07 AM ERROR [JobService] Error: Input file is missing: upload/library/admin/2022/2022-12-13/Screenshot_20221213-20xxxx.png immich_microservices | [Nest] 7 - 11/16/2023, 12:01:07 AM ERROR [JobService] Unable to run job handler (thumbnailGeneration/generate-webp-thumbnail): Error: Input file is missing: upload/library/admin/2022/2022-12-13/Screenshot_20221213-20xxxx.png ``` It's only two files actually and both have leading "Screenshot" but there are 9 instances of the error. This is all I see grepping for the 2012 year. Clearly my server's clock is incorrect so ignore the other time issue above about being 9pm. Edit: guess the classifier is processing these images since it is updating (but also not important here)
OVERLORD commented 2026-02-05 02:52:34 +03:00
Author
Owner
Copy Link

@stevenwalton commented on GitHub (Nov 20, 2023):

Following up, I restarted the servers and gave it a try. I let them sit for awhile (30 mins ish). Seeing no actions being produced in the logs and power draw and top output normalized, so I shut down and updated. So I am now on server v1.87.0. No logs are being produced other than the actions I perform and the problem persists.

Is there a way to force a recheck? This would also be useful as I do have some photos that did not properly upload. This is likely unrelated but just trying to provide additional info. Similarly a likely unrelated issue is that some files did upload that were not from the google photo folders I selected, such as album art. I understand there is some update mechanism but I am unsure what the proper call for this is.

@stevenwalton commented on GitHub (Nov 20, 2023): Following up, I restarted the servers and gave it a try. I let them sit for awhile (30 mins ish). Seeing no actions being produced in the logs and power draw and top output normalized, so I shut down and updated. So I am now on server v1.87.0. No logs are being produced other than the actions I perform and the problem persists. Is there a way to force a recheck? This would also be useful as I do have some photos that did not properly upload. This is likely unrelated but just trying to provide additional info. Similarly a likely unrelated issue is that some files did upload that were not from the google photo folders I selected, such as album art. I understand there is some update mechanism but I am unsure what the proper call for this is.
OVERLORD commented 2026-02-05 02:52:40 +03:00
Author
Owner
Copy Link

@stevenwalton commented on GitHub (Dec 1, 2023):

Okay, so I looked at this problem a bit more and I think I figured out what's going on. I'm pretty sure Immich is reading the wrong exif tag. This is a rather weird thing that I found, but looking at my sidecar data I find that the only valuable metadata is the description, album name, and people that are tagged in photos (may be nice to integrate with the face identification and you can automatically tag people by name!). GPS data and creation time data is wrong.

The bigger issue, is that looking at exif data in the actual image itself there's multiple versions of some tags, specifically time. I believe Google is prepending data and so it just stacks up. But we have unique tags that do have the correct value and so I believe those should take priority if they're found.

Let's see an example

Some data removed for privacy or readability (there are >120 tags!)

$ exiftool PXL_20231129_043736033.jpg 

ExifTool Version Number         : 12.70
File Name                       : PXL_20231129_043736033.jpg
Directory                       : .
File Size                       : 1763 kB
File Modification Date/Time     : 2023:11:30 20:39:18-08:00
File Access Date/Time           : 2023:11:30 20:39:21-08:00
File Inode Change Date/Time     : 2023:11:30 20:39:19-08:00
File Permissions                : -rw-r--r--
File Type                       : JPEG
File Type Extension             : jpg
MIME Type                       : image/jpeg
Exif Byte Order                 : Little-endian (Intel, II)
Make                            : Google
Camera Model Name               : Pixel 6 Pro
...
Modify Date                     : 2023:11:28 20:37:36
...
Date/Time Original              : 2023:11:28 20:37:36
Create Date                     : 2023:11:28 20:37:36
Offset Time                     : -08:00
Offset Time Original            : -08:00
Offset Time Digitized           : -08:00
....
GPS Time Stamp                  : 04:37:30
GPS Date Stamp                  : 2023:11:29
...
Profile Date Time               : A long time ago in a galaxy far away
...
Create Date                     : 2023:11:28 20:37:36.022-08:00
Date/Time Original              : 2023:11:28 20:37:36.022-08:00
Modify Date                     : 2023:11:28 20:37:36.022-08:00
GPS Altitude                    : ...
GPS Date/Time                   : 2023:11:29 04:37:30Z
...

So we'll remember that Google names the files based on the UTC timestamp (which is why I redacted in my first message). So PXL_20231129_043736033.jpg => 29 Nov 2023 at 4:37:73 UTC, I'm in PST (indicated by the -08:00) so that's 20:37. We see that the first instance of the tags Modify Date,Date/Time Original, and Create Date are suspiciously close to the time of this comment and in local time (and indicating the timezone information). Times might be similar but that's coincidence, notice the date. We probably shouldn't trust these ones. But these same tags along with GPS Date/Time are the actual time the photo was taken and correspond to the correct time (GPS has Z, so presumably Zulu, and the small difference may just be GPS drift). We'll ignore GPS date time though because a user may not have that enabled. We can't rely on GPS data though because if you don't have it on then it won't be included.

Going through a bunch of files I find that in every case it was always the last instance of Modify Date,Date/Time Original, and Create Date that was correct and the first instance was not guaranteed. I mentioned earlier that they prepend, and the belief for this is that this exactly corresponds with the time I uploaded that photo to Google photos, which is why it's so close to this comment's time.

TLDR: use the last instance of the Date/Time Original tag and you're all good.

Edit: unrelated side note, google seems to have updated the motion picture file extension to "MP". Exif shows the mime type is video/mp4 and if you change the file extension they read just fine. Idk how Immich handles this, but it seems the future proof way would be to rely on exif data instead of extensions because it looks like (via github search) you whitelist the extensions.

@stevenwalton commented on GitHub (Dec 1, 2023): Okay, so I looked at this problem a bit more and I think I figured out what's going on. I'm pretty sure Immich is reading the wrong exif tag. This is a rather weird thing that I found, but looking at my sidecar data I find that the only valuable metadata is the description, album name, and people that are tagged in photos (may be nice to integrate with the face identification and you can automatically tag people by name!). GPS data and creation time data is wrong. The bigger issue, is that looking at exif data in the actual image itself there's multiple versions of some tags, specifically time. I believe Google is prepending data and so it just stacks up. But we have unique tags that do have the correct value and so I believe those should take priority if they're found. Let's see an example Some data removed for privacy or readability (there are >120 tags!) ```json5 $ exiftool PXL_20231129_043736033.jpg ExifTool Version Number : 12.70 File Name : PXL_20231129_043736033.jpg Directory : . File Size : 1763 kB File Modification Date/Time : 2023:11:30 20:39:18-08:00 File Access Date/Time : 2023:11:30 20:39:21-08:00 File Inode Change Date/Time : 2023:11:30 20:39:19-08:00 File Permissions : -rw-r--r-- File Type : JPEG File Type Extension : jpg MIME Type : image/jpeg Exif Byte Order : Little-endian (Intel, II) Make : Google Camera Model Name : Pixel 6 Pro ... Modify Date : 2023:11:28 20:37:36 ... Date/Time Original : 2023:11:28 20:37:36 Create Date : 2023:11:28 20:37:36 Offset Time : -08:00 Offset Time Original : -08:00 Offset Time Digitized : -08:00 .... GPS Time Stamp : 04:37:30 GPS Date Stamp : 2023:11:29 ... Profile Date Time : A long time ago in a galaxy far away ... Create Date : 2023:11:28 20:37:36.022-08:00 Date/Time Original : 2023:11:28 20:37:36.022-08:00 Modify Date : 2023:11:28 20:37:36.022-08:00 GPS Altitude : ... GPS Date/Time : 2023:11:29 04:37:30Z ... ``` So we'll remember that Google names the files based on the UTC timestamp (which is why I redacted in my first message). So `PXL_20231129_043736033.jpg ` => 29 Nov 2023 at 4:37:73 UTC, I'm in PST (indicated by the -08:00) so that's 20:37. We see that the first instance of the tags `Modify Date`,`Date/Time Original`, and `Create Date` are suspiciously close to the time of this comment and in local time (and indicating the timezone information). Times might be similar but that's coincidence, notice the date. We probably shouldn't trust these ones. But ***these same tags*** along with `GPS Date/Time` are the actual time the photo was taken and correspond to the correct time (GPS has Z, so presumably Zulu, and the small difference may just be GPS drift). We'll ignore GPS date time though because a user may not have that enabled. We can't rely on GPS data though because if you don't have it on then it won't be included. Going through a bunch of files I find that in every case it was always the last instance of `Modify Date`,`Date/Time Original`, and `Create Date` that was correct and the first instance was not guaranteed. I mentioned earlier that they prepend, and the belief for this is that this exactly corresponds with the time I uploaded that photo to Google photos, which is why it's so close to this comment's time. TLDR: use the ***last*** instance of the `Date/Time Original` tag and you're all good. Edit: unrelated side note, google seems to have updated the motion picture file extension to "MP". Exif shows the mime type is video/mp4 and if you change the file extension they read just fine. Idk how Immich handles this, but it seems the future proof way would be to rely on exif data instead of extensions because it looks like (via github search) you whitelist the extensions.
OVERLORD commented 2026-02-05 02:52:42 +03:00
Author
Owner
Copy Link

@Batwam commented on GitHub (Dec 1, 2023):

Rather than using the "last" instance, you probably want to find the accurate tag name (rather than description) you want to rely on since multiple tag appears to have Date/Time Original in their description.

What is the full name of the tag you'd want to use ("last" tag) if you do exiftool -s -time:all PXL_20231129_043736033.jpg?

@Batwam commented on GitHub (Dec 1, 2023): Rather than using the "last" instance, you probably want to find the accurate [tag name](https://exiftool.org/TagNames/) (rather than description) you want to rely on since multiple tag appears to have `Date/Time Original` in their description. What is the full name of the tag you'd want to use ("last" tag) if you do `exiftool -s -time:all PXL_20231129_043736033.jpg`?
OVERLORD commented 2026-02-05 02:52:45 +03:00
Author
Owner
Copy Link

@stevenwalton commented on GitHub (Dec 1, 2023):

$ exiftool -s -time:all PXL_20231129_043736033.jpg

FileModifyDate                  : 2023:11:30 20:39:18-08:00
FileAccessDate                  : 2023:11:30 21:49:18-08:00
FileInodeChangeDate             : 2023:11:30 21:40:08-08:00
ModifyDate                      : 2023:11:28 20:37:36
DateTimeOriginal                : 2023:11:28 20:37:36
CreateDate                      : 2023:11:28 20:37:36
OffsetTime                      : -08:00
OffsetTimeOriginal              : -08:00
OffsetTimeDigitized             : -08:00
SubSecTime                      : 022
SubSecTimeOriginal              : 022
SubSecTimeDigitized             : 022
GPSTimeStamp                    : 04:37:30
GPSDateStamp                    : 2023:11:29
ProfileDateTime                 : 2016:12:08 09:38:28
SubSecCreateDate                : 2023:11:28 20:37:36.022-08:00
SubSecDateTimeOriginal          : 2023:11:28 20:37:36.022-08:00
SubSecModifyDate                : 2023:11:28 20:37:36.022-08:00
GPSDateTime                     : 2023:11:29 04:37:30Z

So CreateDate looks good here. But I'm trying to think of this in general because Immich needs to not just read google photos, but many others. In the other issue that referenced this one, I picked a random imgur image that didn't have integers in the name. Let's do the same

$ exiftool -s -time:all Downloads/jEkVxub.gif

FileModifyDate                  : 2023:11:30 23:03:57-08:00
FileAccessDate                  : 2023:11:30 23:03:58-08:00
FileInodeChangeDate             : 2023:11:30 23:03:57-08:00

That does correspond to me downloading right now but you can see that they are different tags. So it makes sense that you would pull time data from something like FileModifyDate but if we used that tag for the Pixel image we'd get the wrong date, which is exactly what happened for the original issue. I'm not going to pretend to be an expert on this and I'm sure there's better solutions, but to me this is indicating there needs to be a hierarchy of tags that take precedence over another because there's clearly no universal option. You can't even take the earliest date since the profile date is way off. Which kinda sucks, but it very much explains the problem that is the reason for this issue in the first place.

(I'm trying to see if I have a picture from an iPhone somewhere and I'll edit the comment at that time)
Edit: Found a photo from an iPhone but downloaded from Google photos. It has all the same tags as the pixel photo except it is missing the GPS tags and SubSecTime (and the profile time has a dummy value). CreateDate looks to be the correct one but again is in local time.

Let's try to get on topic though: What is Immich using?

@stevenwalton commented on GitHub (Dec 1, 2023): ```json5 $ exiftool -s -time:all PXL_20231129_043736033.jpg FileModifyDate : 2023:11:30 20:39:18-08:00 FileAccessDate : 2023:11:30 21:49:18-08:00 FileInodeChangeDate : 2023:11:30 21:40:08-08:00 ModifyDate : 2023:11:28 20:37:36 DateTimeOriginal : 2023:11:28 20:37:36 CreateDate : 2023:11:28 20:37:36 OffsetTime : -08:00 OffsetTimeOriginal : -08:00 OffsetTimeDigitized : -08:00 SubSecTime : 022 SubSecTimeOriginal : 022 SubSecTimeDigitized : 022 GPSTimeStamp : 04:37:30 GPSDateStamp : 2023:11:29 ProfileDateTime : 2016:12:08 09:38:28 SubSecCreateDate : 2023:11:28 20:37:36.022-08:00 SubSecDateTimeOriginal : 2023:11:28 20:37:36.022-08:00 SubSecModifyDate : 2023:11:28 20:37:36.022-08:00 GPSDateTime : 2023:11:29 04:37:30Z ``` So `CreateDate` looks good here. But I'm trying to think of this in general because Immich needs to not just read google photos, but many others. In the other issue that referenced this one, I picked a random [imgur image](https://imgur.com/jEkVxub) that didn't have integers in the name. Let's do the same ```json5 $ exiftool -s -time:all Downloads/jEkVxub.gif FileModifyDate : 2023:11:30 23:03:57-08:00 FileAccessDate : 2023:11:30 23:03:58-08:00 FileInodeChangeDate : 2023:11:30 23:03:57-08:00 ``` That does correspond to me downloading right now but you can see that they are different tags. So it makes sense that you would pull time data from something like `FileModifyDate` but if we used that tag for the Pixel image we'd get the wrong date, *which is exactly what happened for the original issue.* I'm not going to pretend to be an expert on this and I'm sure there's better solutions, but to me this is indicating there needs to be a hierarchy of tags that take precedence over another because there's clearly no universal option. You can't even take the earliest date since the profile date is way off. Which kinda sucks, but it very much explains the problem that is the reason for this issue in the first place. ~~(I'm trying to see if I have a picture from an iPhone somewhere and I'll edit the comment at that time)~~ Edit: Found a photo from an iPhone but downloaded from Google photos. It has all the same tags as the pixel photo except it is missing the GPS tags and SubSecTime (and the profile time has a dummy value). `CreateDate` looks to be the correct one but again is in local time. Let's try to get on topic though: What is Immich using?
OVERLORD commented 2026-02-05 02:52:48 +03:00
Author
Owner
Copy Link

@Batwam commented on GitHub (Dec 1, 2023):

If I'm not mistaken, it's specified in row #30 of this file

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

Is this prioritisation consistent with what you are seeing?

@Batwam commented on GitHub (Dec 1, 2023): If I'm not mistaken, it's specified in row #30 of [this file](https://github.com/immich-app/immich/blob/main/server/src/domain/metadata/metadata.service.ts) ``` /** look for a date from these tags (in order) */ const EXIF_DATE_TAGS: Array<keyof Tags> = [ 'SubSecDateTimeOriginal', 'DateTimeOriginal', 'SubSecCreateDate', 'CreationDate', 'CreateDate', 'SubSecMediaCreateDate', 'MediaCreateDate', 'DateTimeCreated', ]; ``` Is this prioritisation consistent with what you are seeing?
OVERLORD commented 2026-02-05 02:52:54 +03:00
Author
Owner
Copy Link

@skynetua commented on GitHub (Dec 1, 2023):

Is it possible to not change or at least store somewhere the following dates after uploading?

File Modification Date/Time 
File Access Date/Time 
File Inode Change Date/Time

When photo from messenger is uploaded to imich it shown at date when was received, but after downloading it back from imich it losts this date and shown as today. Google photo has this issue as well.

Found #3900

@skynetua commented on GitHub (Dec 1, 2023): Is it possible to not change or at least store somewhere the following dates after uploading? ``` File Modification Date/Time File Access Date/Time File Inode Change Date/Time ``` When photo from messenger is uploaded to imich it shown at date when was received, but after downloading it back from imich it losts this date and shown as today. Google photo has this issue as well. Found #3900
OVERLORD commented 2026-02-05 02:52:58 +03:00
Author
Owner
Copy Link

@stevenwalton commented on GitHub (Dec 1, 2023):

@Batwam , Sure metadata.service.ts:30 has some information but its not addressing the tags at hand. AND it is not a prioritization list, it is just an array. It's used here and here.

There doesn't appear to be logic that matches DateTimeOriginal and Date/Time Original either. And what The File dates aren't even there. And the lines above look like they're prioritizing sidecar data which my investigation shows to be utterly unreliable. Fwiw, until I switched over to Immich I had a more privacy maximal settings, and I do not think this is an unreasonable belief to assume many other users will be in a similar boat. Sidecar seems only reliable for: Album names, tagging of auxiliary information (such as people), photo description, and view count. It is not consistent with date time nor GPS (I've never been to Null Island but Immich sure thinks I have).

As @skynetua is pointing out, there are plenty of weird issues going on and you can find a lot of open issues with datetime. Certainly we should be at least supporting whatever Google Photos and iCloud are doing. But it also seems to be an evolving environment and as is typical, anything to do with time is just a mess. My domain expertise is not really going to help here (I'd be better providing support on the ML side) so all I can do is report what I see and make a suggestion that should really only be a launching point not a solution (better suited for someone that actually understands all this exif mess haha)

@stevenwalton commented on GitHub (Dec 1, 2023): @Batwam , Sure [metadata.service.ts:30](https://github.com/immich-app/immich/blob/main/server/src/domain/metadata/metadata.service.ts#L30) has some information but its not addressing the tags at hand. AND it is not a prioritization list, it is just an array. It's used [here](https://github.com/immich-app/immich/blob/main/server/src/domain/metadata/metadata.service.ts#L376-L389) and [here](https://github.com/immich-app/immich/blob/main/server/src/domain/metadata/metadata.service.ts#L426-L431). There doesn't appear to be logic that matches `DateTimeOriginal` and `Date/Time Original` either. And what The `File` dates aren't even there. And the lines above look like they're prioritizing sidecar data which my investigation shows to be utterly unreliable. Fwiw, until I switched over to Immich I had a more privacy maximal settings, and I do not think this is an unreasonable belief to assume many other users will be in a similar boat. Sidecar seems only reliable for: Album names, tagging of auxiliary information (such as people), photo description, and view count. It is not consistent with date time nor GPS (I've never been to Null Island but Immich sure thinks I have). As @skynetua is pointing out, there are plenty of weird issues going on and you can find a lot of open issues with datetime. Certainly we should be at least supporting whatever Google Photos and iCloud are doing. But it also seems to be an evolving environment and as is typical, anything to do with time is just a mess. My domain expertise is not really going to help here (I'd be better providing support on the ML side) so all I can do is report what I see and make a suggestion that should really only be a launching point not a solution (better suited for someone that actually understands all this exif mess haha)
OVERLORD commented 2026-02-05 02:53:07 +03:00
Author
Owner
Copy Link

@psyciknz commented on GitHub (Jul 3, 2024):

I believe there is a similar issue when using XMP files. Where they only contain a create/modify date. An asset (upon metadata refresh), then takes the XMP file date.

I think there needs to be the ability to prioritise a date field. Ie a user can select that over everything else, the Exif date taken or Exif DateTimeOriginal takes priority over any other date. Only if that is missing should a file date be used.

It was discussed on discord here: https://discord.com/channels/979116623879368755/1257530194827411517 And rather than create a new issue as it does seem to be the same issue that is described here (date field priority). I chose to append to here. I can create new issue if preferred.

@psyciknz commented on GitHub (Jul 3, 2024): I believe there is a similar issue when using XMP files. Where they only contain a create/modify date. An asset (upon metadata refresh), then takes the XMP file date. I think there needs to be the ability to prioritise a date field. Ie a user can select that over everything else, the Exif date taken or Exif DateTimeOriginal takes priority over any other date. Only if that is missing should a file date be used. It was discussed on discord here: https://discord.com/channels/979116623879368755/1257530194827411517 And rather than create a new issue as it does seem to be the same issue that is described here (date field priority). I chose to append to here. I can create new issue if preferred.
OVERLORD commented 2026-02-05 02:53:15 +03:00
Author
Owner
Copy Link

@zmc commented on GitHub (Jul 15, 2024):

Trying out Immich for the first time, and just finished backing up all my Google Photos to my instance via the mobile app. I've just noticed a large amount of photos with incorrect dates. Here's the exif information for one of them:

ExifTool Version Number         : 12.70
File Name                       : IMG_20170213_201229_344.jpg
Directory                       : library/admin/2021/11/03
File Size                       : 6.1 MB
File Modification Date/Time     : 2017:02:13 21:12:30-07:00
File Access Date/Time           : 2024:07:14 00:58:24-06:00
File Inode Change Date/Time     : 2017:02:13 21:12:30-07:00
File Permissions                : -rwxr-xr-x
File Type                       : JPEG
File Type Extension             : jpg
MIME Type                       : image/jpeg
Exif Byte Order                 : Big-endian (Motorola, MM)
Light Source                    : Unknown
Orientation                     : Unknown (0)
GPS Latitude Ref                : North
GPS Longitude Ref               : West
JFIF Version                    : 1.01
Resolution Unit                 : None
X Resolution                    : 1
Y Resolution                    : 1
Image Width                     : 3036
Image Height                    : 3036
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                      : 3036x3036
Megapixels                      : 9.2

So this image is considered to be from 2021-11-03, when in fact it was taken on 2017-02-13. Exif agrees, the filename agrees... and Immich seems to ignore it all. No jobs are running, and rerunning the "extract metadata" and "storage template migration" didn't fix them.

@zmc commented on GitHub (Jul 15, 2024): Trying out Immich for the first time, and just finished backing up all my Google Photos to my instance via the mobile app. I've just noticed a large amount of photos with incorrect dates. Here's the exif information for one of them: ``` ExifTool Version Number : 12.70 File Name : IMG_20170213_201229_344.jpg Directory : library/admin/2021/11/03 File Size : 6.1 MB File Modification Date/Time : 2017:02:13 21:12:30-07:00 File Access Date/Time : 2024:07:14 00:58:24-06:00 File Inode Change Date/Time : 2017:02:13 21:12:30-07:00 File Permissions : -rwxr-xr-x File Type : JPEG File Type Extension : jpg MIME Type : image/jpeg Exif Byte Order : Big-endian (Motorola, MM) Light Source : Unknown Orientation : Unknown (0) GPS Latitude Ref : North GPS Longitude Ref : West JFIF Version : 1.01 Resolution Unit : None X Resolution : 1 Y Resolution : 1 Image Width : 3036 Image Height : 3036 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 : 3036x3036 Megapixels : 9.2 ``` So this image is considered to be from 2021-11-03, when in fact it was taken on 2017-02-13. Exif agrees, the filename agrees... and Immich seems to ignore it all. No jobs are running, and rerunning the "extract metadata" and "storage template migration" didn't fix them.
OVERLORD commented 2026-02-05 02:53:19 +03:00
Author
Owner
Copy Link

@psyciknz commented on GitHub (Jul 15, 2024):

Trying out Immich for the first time, and just finished backing up all my Google Photos to my instance via the mobile app. I've just noticed a large amount of photos with incorrect dates. Here's the exif information for one of them:

ExifTool Version Number         : 12.70
File Name                       : IMG_20170213_201229_344.jpg
Directory                       : library/admin/2021/11/03
File Size                       : 6.1 MB
File Modification Date/Time     : 2017:02:13 21:12:30-07:00
File Access Date/Time           : 2024:07:14 00:58:24-06:00
File Inode Change Date/Time     : 2017:02:13 21:12:30-07:00
File Permissions                : -rwxr-xr-x
File Type                       : JPEG
File Type Extension             : jpg
MIME Type                       : image/jpeg
Exif Byte Order                 : Big-endian (Motorola, MM)
Light Source                    : Unknown
Orientation                     : Unknown (0)
GPS Latitude Ref                : North
GPS Longitude Ref               : West
JFIF Version                    : 1.01
Resolution Unit                 : None
X Resolution                    : 1
Y Resolution                    : 1
Image Width                     : 3036
Image Height                    : 3036
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                      : 3036x3036
Megapixels                      : 9.2

So this image is considered to be from 2021-11-03, when in fact it was taken on 2017-02-13. Exif agrees, the filename agrees... and Immich seems to ignore it all. No jobs are running, and rerunning the "extract metadata" and "storage template migration" didn't fix them.

Lack of TImeTaken would be a problem. How can immich be expected to choose between date modified and date created. Thats where the specific TimeTaken and TimeTakenOriginal are so good.

@psyciknz commented on GitHub (Jul 15, 2024): > Trying out Immich for the first time, and just finished backing up all my Google Photos to my instance via the mobile app. I've just noticed a large amount of photos with incorrect dates. Here's the exif information for one of them: > > ``` > ExifTool Version Number : 12.70 > File Name : IMG_20170213_201229_344.jpg > Directory : library/admin/2021/11/03 > File Size : 6.1 MB > File Modification Date/Time : 2017:02:13 21:12:30-07:00 > File Access Date/Time : 2024:07:14 00:58:24-06:00 > File Inode Change Date/Time : 2017:02:13 21:12:30-07:00 > File Permissions : -rwxr-xr-x > File Type : JPEG > File Type Extension : jpg > MIME Type : image/jpeg > Exif Byte Order : Big-endian (Motorola, MM) > Light Source : Unknown > Orientation : Unknown (0) > GPS Latitude Ref : North > GPS Longitude Ref : West > JFIF Version : 1.01 > Resolution Unit : None > X Resolution : 1 > Y Resolution : 1 > Image Width : 3036 > Image Height : 3036 > 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 : 3036x3036 > Megapixels : 9.2 > ``` > > So this image is considered to be from 2021-11-03, when in fact it was taken on 2017-02-13. Exif agrees, the filename agrees... and Immich seems to ignore it all. No jobs are running, and rerunning the "extract metadata" and "storage template migration" didn't fix them. Lack of TImeTaken would be a problem. How can immich be expected to choose between date modified and date created. Thats where the specific TimeTaken and TimeTakenOriginal are so good.
OVERLORD commented 2026-02-05 02:53:21 +03:00
Author
Owner
Copy Link

@stevenwalton commented on GitHub (Jul 15, 2024):

How can immich be expected to choose between date modified and date created.

I believe we discussed a lot of this with what I brought up earlier. I'm sure that someone knows much more about the typical formatting of filenames and exif data, but it is pretty clear that Google modifies values. So there's a few things that can be checked.

First, in both our cases, and to the best of my knowledge, the earliest date is never an obtuse one. So why not look at several and default to the earliest? I'm very willing to believe that there's a reason, I'd just like to know.

Second, we do know for a fact that filenames often contain date data. Why not use this? We can check for it with a regex. In our case something like ^[A-Z]{3}_(19|20)\d{2}(0\d|1[0-2])(0\d|(1|2)\d|3[0-1])_\d+.*\.(?i)(jp.?g|png)$ works great (check for 3 leading capital letters, followed by _ then a year in 1900/2000 followed by a month (01-12), followed by a day <31, followed by another _, numbers, anything, and ending in a case insensitive extension of {jpg,jpeg,png}). Or maybe even a simpler version .*(19|20)\d{2}(0\d|1[0-2])(0\d|(1|2)\d|3[0-1]).*\.(?i)(jp.?g|png)$1 that just looks for a date format inside anything. Will there be errors? Sure. 20111111.jpg is ambiguous and we don't support pictures taken in the year 2100. But there are already ones here that are creating enough problems. I'm also very willing to believe there's naming conventions I'm not aware of.

The most reasonable approach to me seems to me to mark these images when they're being imported. To do the best to guess what the actual date should be, based on the context of the other exif data AND filename (given there is a match). And then allow the user to update the determined date, providing them a selection of the unique values extracted or to explicitly define one. This provides users with a simple means to correct the data while also not requiring any technical know-how.

While I think we can expect the person setting up the server to be technical, we should not expect the user to be. Plus, a little code saves a lot of time, especially when people don't know how to modify these things. Providing "smart" suggestions for dates can just be part of the normal edit date and time method. (The same can be true about the timezone suggestion, where you can place the timezone associated with the GPS data, if it exists, followed by the timezone's of a person's country based on the currently defined locale, and then sorted. I'm sure I'm not the only one who hates how frequently we have to scroll given the unnecessary nature of it.) Not to mention that even if the person is technical, it still is going to save them time and effort.

We're programmers and these are problems we can solve. Do we need a annoying set of conditional? Yes. But timezones and time are famously messy. We can at least do a bit better than we are now, and I don't see why we shouldn't want to improve. Improving a bit will reduce errors, help users, and reduce the number of issues related to bad dates.

  1. I'm pretty sure formats will be in <something>_date_<something>.extension or date.extension in which case ^([A-Z]*_|)(19|20)\d{2}(0\d|1[0-2])(0\d|(1|2)\d|3[0-1])(|_.*)\.(?i)(jp.?g|png)$ will glob that. On the off chance we have a - deliminator, change _ to (-|_). ↩︎

@stevenwalton commented on GitHub (Jul 15, 2024): > How can immich be expected to choose between date modified and date created. I believe we discussed a lot of this with what I brought up earlier. I'm sure that someone knows much more about the typical formatting of filenames and exif data, but it is pretty clear that Google modifies values. So there's a few things that can be checked. First, in both our cases, and to the best of my knowledge, the earliest date is never an obtuse one. So why not look at several and default to the earliest? I'm **_very_** willing to believe that there's a reason, I'd just like to know. Second, we do know for a fact that filenames often contain date data. Why not use this? We can check for it with a regex. In our case something like `^[A-Z]{3}_(19|20)\d{2}(0\d|1[0-2])(0\d|(1|2)\d|3[0-1])_\d+.*\.(?i)(jp.?g|png)$` works great (check for 3 leading capital letters, followed by `_` then a year in 1900/2000 followed by a month (01-12), followed by a day <31, followed by another `_`, numbers, anything, and ending in a case insensitive extension of `{jpg,jpeg,png}`). Or maybe even a simpler version `.*(19|20)\d{2}(0\d|1[0-2])(0\d|(1|2)\d|3[0-1]).*\.(?i)(jp.?g|png)$`[^1] that just looks for a date format inside anything. Will there be errors? Sure. 20111111.jpg is ambiguous and we don't support pictures taken in the year 2100. But there are already ones here that are creating enough problems. I'm also very willing to believe there's naming conventions I'm not aware of. The most reasonable approach to me seems to me to mark these images when they're being imported. To do the best to guess what the actual date should be, based on the context of the other exif data AND filename (given there is a match). And then allow the user to update the determined date, providing them a selection of the unique values extracted or to explicitly define one. This provides users with a simple means to correct the data while also not requiring any technical know-how. While I think we can expect the person setting up the server to be technical, we should not expect the user to be. Plus, a little code saves a lot of time, especially when people don't know how to modify these things. Providing "smart" suggestions for dates can just be part of the normal edit date and time method. (The same can be true about the timezone suggestion, where you can place the timezone associated with the GPS data, if it exists, followed by the timezone's of a person's country based on the currently defined locale, and then sorted. I'm sure I'm not the only one who hates how frequently we have to scroll given the unnecessary nature of it.) Not to mention that even if the person is technical, it still is going to save them time and effort. We're programmers and these are problems we can solve. Do we need a annoying set of conditional? Yes. But [timezones](https://www.zainrizvi.io/blog/falsehoods-programmers-believe-about-time-zones/) and [time](https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time) are famously messy. We can at least do a bit better than we are now, and I don't see why we shouldn't want to improve. Improving a bit will reduce errors, help users, and reduce the number of issues related to bad dates. [^1]: I'm pretty sure formats will be in `<something>_date_<something>.extension` or `date.extension` in which case `^([A-Z]*_|)(19|20)\d{2}(0\d|1[0-2])(0\d|(1|2)\d|3[0-1])(|_.*)\.(?i)(jp.?g|png)$` will glob that. On the off chance we have a `-` deliminator, change `_` to `(-|_)`.
OVERLORD commented 2026-02-05 02:53:25 +03:00
Author
Owner
Copy Link

@OfficiallyCrazy commented on GitHub (Jul 22, 2024):

I would really like for this problem to be fixed. I love Immich.

@OfficiallyCrazy commented on GitHub (Jul 22, 2024): I would really like for this problem to be fixed. I love Immich.
OVERLORD commented 2026-02-05 02:53:32 +03:00
Author
Owner
Copy Link

@neopet001 commented on GitHub (Aug 11, 2024):

After finish importing all 200.000 photos to immich, I found a mess, everything is crazy! A terrible mess.

In shot, GPS data and creation time data is wrong.

Exif info in files are fine and as showing on Google Photos, dates are right as of iCloud too, same good thing on Synology Photo, but 60% of items date on immich is wrong, and GPS go the different way at all, completely wrong!

Love to see if this is fixed!

Update: refreshing metadata for those files doesn't help. Download the file from immich to desktop and check for exif result in right date while immich shows totally wrong date.

@neopet001 commented on GitHub (Aug 11, 2024): After finish importing all 200.000 photos to immich, I found a mess, everything is crazy! A terrible mess. In shot, GPS data and creation time data is wrong. Exif info in files are fine and as showing on Google Photos, dates are right as of iCloud too, same good thing on Synology Photo, but 60% of items date on immich is wrong, and GPS go the different way at all, completely wrong! Love to see if this is fixed! Update: refreshing metadata for those files doesn't help. Download the file from immich to desktop and check for exif result in right date while immich shows totally wrong date.
OVERLORD commented 2026-02-05 02:53:35 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Aug 11, 2024):

@neopet001 did you use Immich go to import your GPhotos take out?

@alextran1502 commented on GitHub (Aug 11, 2024): @neopet001 did you use Immich go to import your GPhotos take out?
OVERLORD commented 2026-02-05 02:53:41 +03:00
Author
Owner
Copy Link

@neopet001 commented on GitHub (Aug 11, 2024):

@neopet001 did you use Immich go to import your GPhotos take out?

Yes I did, used
upload -google-photos ./takeout-*.zip

Wondering if deleting all json and import only photos might help?

Maybe I need to re-read all the docs to understand how "Refresh metadata" work, whether it reload sidecar file or re-read exif from the photo files? I tried refreshing metadata but the date and gps stayed still.

@neopet001 commented on GitHub (Aug 11, 2024): > @neopet001 did you use Immich go to import your GPhotos take out? Yes I did, used `upload -google-photos ./takeout-*.zip` Wondering if deleting all json and import only photos might help? Maybe I need to re-read all the docs to understand how "Refresh metadata" work, whether it reload sidecar file or re-read exif from the photo files? I tried refreshing metadata but the date and gps stayed still.
OVERLORD commented 2026-02-05 02:53:45 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Aug 11, 2024):

@neopet001 if you don't import with the json file, all the metadata will be lost afaik

@alextran1502 commented on GitHub (Aug 11, 2024): @neopet001 if you don't import with the json file, all the metadata will be lost afaik
OVERLORD commented 2026-02-05 02:53:48 +03:00
Author
Owner
Copy Link

@neopet001 commented on GitHub (Aug 11, 2024):

afaik

So what to do with all the wrong dates? It's ok on every other systems but not immich.

Here are the comparison:

  1. Human memory: correct photo taken date: March 11th, 2022

  2. File exif (with correct taken date, downloaded from Immich):
    image
    image

  3. Google photo:
    image

  4. Synology photos (image filename was edit due to synology photos rule that I set upon backup):
    image

  5. Immich web:
    image

  6. Immich on ios:
    image

Idk what's wrong but where did Immich get that date?

@neopet001 commented on GitHub (Aug 11, 2024): > afaik So what to do with all the wrong dates? It's ok on every other systems but not immich. Here are the comparison: 1. Human memory: correct photo taken date: March 11th, 2022 2. File exif (with correct taken date, downloaded from Immich): ![image](https://github.com/user-attachments/assets/a2682492-5007-4641-aad9-15178878f9fb) ![image](https://github.com/user-attachments/assets/8d01d1cf-f611-4414-bb61-a5230d98bb7c) 3. Google photo: ![image](https://github.com/user-attachments/assets/9b93b3e5-fe20-4618-8562-dae9bb65066f) 4. Synology photos (image filename was edit due to synology photos rule that I set upon backup): ![image](https://github.com/user-attachments/assets/c2a06ac5-1624-4e58-89da-c7ec79b047cf) 5. Immich web: ![image](https://github.com/user-attachments/assets/7587e736-0c36-40b8-bece-dfd449107a7a) 6. Immich on ios: ![image](https://github.com/user-attachments/assets/1a0fd8da-3982-4b6e-8f18-838e1b18b427) Idk what's wrong but where did Immich get that date?
OVERLORD commented 2026-02-05 02:53:51 +03:00
Author
Owner
Copy Link

@psyciknz commented on GitHub (Aug 11, 2024):

This is the problem I have as well.

File taken 2019, and an XMP created in the past month. Immich displays the XMP creation date (external library) - ignore the path, only my photoprism contain has the exif tool

ExifTool Version Number         : 12.76
File Name                       : IMG_3403.JPG
Directory                       : originals/MainCamera/2019/2019-07-14_Cyprus_Aphrodite_Paphos
File Size                       : 1651 kB
File Modification Date/Time     : 2023:09:22 14:34:03+00:00
File Access Date/Time           : 2024:08:10 21:43:21+00:00
File Inode Change Date/Time     : 2024:06:29 00:17:20+00:00
File Permissions                : -rw-rw-r--
File Type                       : JPEG
File Type Extension             : jpg
MIME Type                       : image/jpeg
JFIF Version                    : 1.01
Make                            : Panasonic
Camera Model Name               : DMC-GX85
Resolution Unit                 : inches
Modify Date                     : 2019:07:14 18:04:50
Exposure Time                   : 1/250
F Number                        : 5.0
Exposure Program                : Program AE
ISO                             : 200
Sensitivity Type                : Standard Output Sensitivity
Exif Version                    : 0230
Date/Time Original              : 2019:07:14 12:20:56
Create Date                     : 2019:07:14 12:20:56
Components Configuration        : Y, Cb, Cr, -
Light Source                    : Unknown
Flash                           : Off, Did not fire
Custom Rendered                 : Normal
Exposure Mode                   : Auto
White Balance                   : Auto
Digital Zoom Ratio              : 0
Focal Length In 35mm Format     : 24 mm
Scene Capture Type              : Standard
Gain Control                    : Low gain up
GPS Latitude Ref                : North
GPS Longitude Ref               : East
Compression                     : JPEG (old-style)
Thumbnail Offset                : 972
Thumbnail Length                : 11896
XMP Toolkit                     : XMP Core 6.0.0
Serial Number                   : XGL1607040234
Lens                            : LUMIX G VARIO 12-60/F3.5-5.6
Lens Serial Number              : 07CX5143353B
Event                           : Cyprus Paphos
Subject                         : Travel, Cyprus, Paphos, Albums, Cyprus Paphos, 2019 World Trip
Hierarchical Subject            : Travel, Travel|Cyprus, Travel|Cyprus|Paphos, Albums, Albums|2019 World Trip|Cyprus Paphos, Albums|2019 World Trip
Current IPTC Digest             : 6d38222ecb48d058e5c5733550dc2d9c
Coded Character Set             : UTF8
Keywords                        : Travel, Travel|Cyprus, Travel|Cyprus|Paphos, Albums, Albums|2019 World Trip|Cyprus Paphos, Albums|2019 World Trip
Image Width                     : 3232
Image Height                    : 2424
Encoding Process                : Baseline DCT, Huffman coding
Bits Per Sample                 : 8
Color Components                : 3
Y Cb Cr Sub Sampling            : YCbCr4:2:0 (2 2)
Aperture                        : 5.0
Image Size                      : 3232x2424
Megapixels                      : 7.8
Scale Factor To 35 mm Equivalent: 2.0
Shutter Speed                   : 1/250
Create Date                     : 2019:07:14 12:20:56.845
Date/Time Original              : 2019:07:14 12:20:56.845
Modify Date                     : 2019:07:14 18:04:50.845
Thumbnail Image                 : (Binary data 11896 bytes, use -b option to extract)
GPS Latitude                    : 34 deg 45' 16.50" N
GPS Longitude                   : 32 deg 25' 2.41" E
Circle Of Confusion             : 0.015 mm
Field Of View                   : 73.7 deg
Focal Length                    : 12.0 mm (35 mm equivalent: 24.0 mm)
GPS Position                    : 34 deg 45' 16.50" N, 32 deg 25' 2.41" E
Hyperfocal Distance             : 1.92 m
Light Value                     : 11.6
Lens ID                         : LUMIX G VARIO 12-60mm F3.5-5.6

With the XMP as follows:

ExifTool Version Number         : 12.76
File Name                       : IMG_3403.JPG.xmp
Directory                       : originals/MainCamera/2019/2019-07-14_Cyprus_Aphrodite_Paphos
File Size                       : 1812 bytes
File Modification Date/Time     : 2024:06:29 00:17:20+00:00
File Access Date/Time           : 2024:08:10 21:43:22+00:00
File Inode Change Date/Time     : 2024:06:29 00:17:20+00:00
File Permissions                : -rw-rw-r--
File Type                       : XMP
File Type Extension             : xmp
MIME Type                       : application/rdf+xml
XMP Toolkit                     : XMP Core 6.0.0
Warning                         : [minor] Fixed incorrect URI for xmlns:MicrosoftPhoto
Serial Number                   : XGL1607040234
Lens                            : LUMIX G VARIO 12-60/F3.5-5.6
Lens Serial Number              : 07CX5143353B
Create Date                     : 2024:06:29 12:14:38
Modify Date                     : 2024:06:29 12:14:38
Rating                          : 0
Event                           : Cyprus Paphos
Rating Percent                  : 0
Subject                         : Travel, Cyprus, Paphos, Albums, Cyprus Paphos, 2019 World Trip
Hierarchical Subject            : Travel, Travel|Cyprus, Travel|Cyprus|Paphos, Albums, Albums|2019 World Trip|Cyprus Paphos, Albums|2019 World Trip
Lens ID                         : LUMIX G VARIO 12-60mm F3.5-5.6

With immich reporting:
image
Which is from the XMP

Create Date                     : 2024:06:29 12:14:38
Modify Date                     : 2024:06:29 12:14:38

I believe the issue is in prioritising what date should "win" when there are mulitples. And I believe, that original date/time, date time taken, exif fields, if there should win.

@psyciknz commented on GitHub (Aug 11, 2024): This is the problem I have as well. File taken 2019, and an XMP created in the past month. Immich displays the XMP creation date (external library) - ignore the path, only my photoprism contain has the exif tool ``` ExifTool Version Number : 12.76 File Name : IMG_3403.JPG Directory : originals/MainCamera/2019/2019-07-14_Cyprus_Aphrodite_Paphos File Size : 1651 kB File Modification Date/Time : 2023:09:22 14:34:03+00:00 File Access Date/Time : 2024:08:10 21:43:21+00:00 File Inode Change Date/Time : 2024:06:29 00:17:20+00:00 File Permissions : -rw-rw-r-- File Type : JPEG File Type Extension : jpg MIME Type : image/jpeg JFIF Version : 1.01 Make : Panasonic Camera Model Name : DMC-GX85 Resolution Unit : inches Modify Date : 2019:07:14 18:04:50 Exposure Time : 1/250 F Number : 5.0 Exposure Program : Program AE ISO : 200 Sensitivity Type : Standard Output Sensitivity Exif Version : 0230 Date/Time Original : 2019:07:14 12:20:56 Create Date : 2019:07:14 12:20:56 Components Configuration : Y, Cb, Cr, - Light Source : Unknown Flash : Off, Did not fire Custom Rendered : Normal Exposure Mode : Auto White Balance : Auto Digital Zoom Ratio : 0 Focal Length In 35mm Format : 24 mm Scene Capture Type : Standard Gain Control : Low gain up GPS Latitude Ref : North GPS Longitude Ref : East Compression : JPEG (old-style) Thumbnail Offset : 972 Thumbnail Length : 11896 XMP Toolkit : XMP Core 6.0.0 Serial Number : XGL1607040234 Lens : LUMIX G VARIO 12-60/F3.5-5.6 Lens Serial Number : 07CX5143353B Event : Cyprus Paphos Subject : Travel, Cyprus, Paphos, Albums, Cyprus Paphos, 2019 World Trip Hierarchical Subject : Travel, Travel|Cyprus, Travel|Cyprus|Paphos, Albums, Albums|2019 World Trip|Cyprus Paphos, Albums|2019 World Trip Current IPTC Digest : 6d38222ecb48d058e5c5733550dc2d9c Coded Character Set : UTF8 Keywords : Travel, Travel|Cyprus, Travel|Cyprus|Paphos, Albums, Albums|2019 World Trip|Cyprus Paphos, Albums|2019 World Trip Image Width : 3232 Image Height : 2424 Encoding Process : Baseline DCT, Huffman coding Bits Per Sample : 8 Color Components : 3 Y Cb Cr Sub Sampling : YCbCr4:2:0 (2 2) Aperture : 5.0 Image Size : 3232x2424 Megapixels : 7.8 Scale Factor To 35 mm Equivalent: 2.0 Shutter Speed : 1/250 Create Date : 2019:07:14 12:20:56.845 Date/Time Original : 2019:07:14 12:20:56.845 Modify Date : 2019:07:14 18:04:50.845 Thumbnail Image : (Binary data 11896 bytes, use -b option to extract) GPS Latitude : 34 deg 45' 16.50" N GPS Longitude : 32 deg 25' 2.41" E Circle Of Confusion : 0.015 mm Field Of View : 73.7 deg Focal Length : 12.0 mm (35 mm equivalent: 24.0 mm) GPS Position : 34 deg 45' 16.50" N, 32 deg 25' 2.41" E Hyperfocal Distance : 1.92 m Light Value : 11.6 Lens ID : LUMIX G VARIO 12-60mm F3.5-5.6 ``` With the XMP as follows: ``` ExifTool Version Number : 12.76 File Name : IMG_3403.JPG.xmp Directory : originals/MainCamera/2019/2019-07-14_Cyprus_Aphrodite_Paphos File Size : 1812 bytes File Modification Date/Time : 2024:06:29 00:17:20+00:00 File Access Date/Time : 2024:08:10 21:43:22+00:00 File Inode Change Date/Time : 2024:06:29 00:17:20+00:00 File Permissions : -rw-rw-r-- File Type : XMP File Type Extension : xmp MIME Type : application/rdf+xml XMP Toolkit : XMP Core 6.0.0 Warning : [minor] Fixed incorrect URI for xmlns:MicrosoftPhoto Serial Number : XGL1607040234 Lens : LUMIX G VARIO 12-60/F3.5-5.6 Lens Serial Number : 07CX5143353B Create Date : 2024:06:29 12:14:38 Modify Date : 2024:06:29 12:14:38 Rating : 0 Event : Cyprus Paphos Rating Percent : 0 Subject : Travel, Cyprus, Paphos, Albums, Cyprus Paphos, 2019 World Trip Hierarchical Subject : Travel, Travel|Cyprus, Travel|Cyprus|Paphos, Albums, Albums|2019 World Trip|Cyprus Paphos, Albums|2019 World Trip Lens ID : LUMIX G VARIO 12-60mm F3.5-5.6 ``` With immich reporting: ![image](https://github.com/user-attachments/assets/c8c1c51c-9bc5-47c2-b29e-e14ae609f14b) Which is from the XMP ``` Create Date : 2024:06:29 12:14:38 Modify Date : 2024:06:29 12:14:38 ``` I believe the issue is in prioritising what date should "win" when there are mulitples. And I believe, that original date/time, date time taken, exif fields, if there should win.
OVERLORD commented 2026-02-05 02:53:55 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Aug 11, 2024):

@neopet001 Can you attach the file above for troubleshooting? Cảm ơn!

@psyciknz FWIW, here is the list of date tags that get read and ordered by priority; I think when an XMP file is present, it will override EXIF's priority. Because XMP file get created when the file is modified, which mean the original information of the file is either incorrect or purposely changed by the owner

/** look for a date from these tags (in order) */
const EXIF_DATE_TAGS: Array<keyof Tags> = [
  'SubSecDateTimeOriginal',
  'DateTimeOriginal',
  'SubSecCreateDate',
  'CreationDate',
  'CreateDate',
  'SubSecMediaCreateDate',
  'MediaCreateDate',
  'DateTimeCreated',
];
@alextran1502 commented on GitHub (Aug 11, 2024): @neopet001 Can you attach the file above for troubleshooting? Cảm ơn! @psyciknz FWIW, here is the list of date tags that get read and ordered by priority; I think when an XMP file is present, it will override EXIF's priority. Because XMP file get created when the file is modified, which mean the original information of the file is either incorrect or purposely changed by the owner ```ts /** look for a date from these tags (in order) */ const EXIF_DATE_TAGS: Array<keyof Tags> = [ 'SubSecDateTimeOriginal', 'DateTimeOriginal', 'SubSecCreateDate', 'CreationDate', 'CreateDate', 'SubSecMediaCreateDate', 'MediaCreateDate', 'DateTimeCreated', ]; ```
OVERLORD commented 2026-02-05 02:53:58 +03:00
Author
Owner
Copy Link

@psyciknz commented on GitHub (Aug 12, 2024):

@neopet001 Can you attach the file above for troubleshooting? Cảm ơn!

@psyciknz FWIW, here is the list of date tags that get read and ordered by priority; I think when an XMP file is present, it will override EXIF's priority. Because XMP file get created when the file is modified, which mean the original information of the file is either incorrect or purposely changed by the owner

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

Are these two different issues, or related? I can split if you prefer.

Even if xmp is there, shouldn't 'Date/Time Original : 2019:07:14 12:20:56.845' take priority? As an xmp may/may not include that as it's (IMO) not generally the full exif data is it, but supplimental.

@psyciknz commented on GitHub (Aug 12, 2024): > @neopet001 Can you attach the file above for troubleshooting? Cảm ơn! > > @psyciknz FWIW, here is the list of date tags that get read and ordered by priority; I think when an XMP file is present, it will override EXIF's priority. Because XMP file get created when the file is modified, which mean the original information of the file is either incorrect or purposely changed by the owner > > ```ts > /** look for a date from these tags (in order) */ > const EXIF_DATE_TAGS: Array<keyof Tags> = [ > 'SubSecDateTimeOriginal', > 'DateTimeOriginal', > 'SubSecCreateDate', > 'CreationDate', > 'CreateDate', > 'SubSecMediaCreateDate', > 'MediaCreateDate', > 'DateTimeCreated', > ]; > ``` Are these two different issues, or related? I can split if you prefer. Even if xmp is there, shouldn't 'Date/Time Original : 2019:07:14 12:20:56.845' take priority? As an xmp may/may not include that as it's (IMO) not generally the full exif data is it, but supplimental.
OVERLORD commented 2026-02-05 02:54:00 +03:00
Author
Owner
Copy Link

@neopet001 commented on GitHub (Aug 12, 2024):

@neopet001 Can you attach the file above for troubleshooting? Cảm ơn!

@psyciknz FWIW, here is the list of date tags that get read and ordered by priority; I think when an XMP file is present, it will override EXIF's priority. Because XMP file get created when the file is modified, which mean the original information of the file is either incorrect or purposely changed by the owner

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

Sure here it is
IMG_4411.zip

Whatever, thank you for your incomparable dedication.

@neopet001 commented on GitHub (Aug 12, 2024): > @neopet001 Can you attach the file above for troubleshooting? Cảm ơn! > > @psyciknz FWIW, here is the list of date tags that get read and ordered by priority; I think when an XMP file is present, it will override EXIF's priority. Because XMP file get created when the file is modified, which mean the original information of the file is either incorrect or purposely changed by the owner > > ```ts > /** look for a date from these tags (in order) */ > const EXIF_DATE_TAGS: Array<keyof Tags> = [ > 'SubSecDateTimeOriginal', > 'DateTimeOriginal', > 'SubSecCreateDate', > 'CreationDate', > 'CreateDate', > 'SubSecMediaCreateDate', > 'MediaCreateDate', > 'DateTimeCreated', > ]; > ``` Sure here it is [IMG_4411.zip](https://github.com/user-attachments/files/16576920/IMG_4411.zip) Whatever, thank you for your incomparable dedication.
OVERLORD commented 2026-02-05 02:54:03 +03:00
Author
Owner
Copy Link

@neopet001 commented on GitHub (Aug 28, 2024):

Tried installing a brandnew immich instant today, uploaded again and the GPS & Date are wrong as before.
Love to know if there's any on-going fix or workaround for this core feature, as date is very important to date to sort and view.

@neopet001 commented on GitHub (Aug 28, 2024): Tried installing a brandnew immich instant today, uploaded again and the GPS & Date are wrong as before. Love to know if there's any on-going fix or workaround for this core feature, as date is very important to date to sort and view.
OVERLORD commented 2026-02-05 02:54:09 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Aug 28, 2024):

@neopet001 So this is what I see, what do you see on your end?
image

@alextran1502 commented on GitHub (Aug 28, 2024): @neopet001 So this is what I see, what do you see on your end? ![image](https://github.com/user-attachments/assets/c9e8e414-89f8-4e07-be8b-f50a4b853a5c)
OVERLORD commented 2026-02-05 02:54:17 +03:00
Author
Owner
Copy Link

@t0rv1c commented on GitHub (Aug 29, 2024):

Hi!
Same here: I have this original picture that I have uploaded (I did it twice: Immich-go and immich-cli) and the results are the same

This is the original:
image

This is how it is in immich:
XMP

<?xpacket begin='?' id='W5M0MpCehiHzreSzNTczkc9d'?>
<x:xmpmeta xmlns:x='adobe:ns:meta/' x:xmptk='Image::ExifTool 12.40'>
<rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
 <rdf:Description rdf:about=''
  xmlns:exif='http://ns.adobe.com/exif/1.0/'>
  <exif:ExifVersion>0220</exif:ExifVersion>  <exif:DateTimeOriginal>2007-07-04T09:00:00Z</exif:DateTimeOriginal>
  <exif:GPSVersionID>2.3.0.0</exif:GPSVersionID>
 </rdf:Description>
</rdf:RDF>
</x:xmpmeta>
<?xpacket end='w'?>

And in the app:
image

I guess it's using my locale for the date (GMT-10) so the date is different but it's the XMP's.

It looks like there is an issue in the process with ExifTool....
Thanks for your help!

@t0rv1c commented on GitHub (Aug 29, 2024): Hi! Same here: I have this original picture that I have uploaded (I did it twice: Immich-go and immich-cli) and the results are the same This is the original: ![image](https://github.com/user-attachments/assets/f3c29cd3-4919-4959-a18d-315f6c0a6585) This is how it is in immich: XMP ```xmp <?xpacket begin='?' id='W5M0MpCehiHzreSzNTczkc9d'?> <x:xmpmeta xmlns:x='adobe:ns:meta/' x:xmptk='Image::ExifTool 12.40'> <rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'> <rdf:Description rdf:about='' xmlns:exif='http://ns.adobe.com/exif/1.0/'> <exif:ExifVersion>0220</exif:ExifVersion> <exif:DateTimeOriginal>2007-07-04T09:00:00Z</exif:DateTimeOriginal> <exif:GPSVersionID>2.3.0.0</exif:GPSVersionID> </rdf:Description> </rdf:RDF> </x:xmpmeta> <?xpacket end='w'?> ``` And in the app: ![image](https://github.com/user-attachments/assets/06129849-da38-4c89-8639-070553f70bf3) I guess it's using my locale for the date (GMT-10) so the date is different but it's the XMP's. It looks like there is an issue in the process with ExifTool.... Thanks for your help!
OVERLORD commented 2026-02-05 02:54:24 +03:00
Author
Owner
Copy Link

@stevenwalton commented on GitHub (Sep 1, 2024):

@alextran1502 is there something wrong with what I proposed?

I do not think this is an issue that can be solved by using a preferential list of Exif dates. Think about how we humans can determine the actual date from the reported Exif data (see mine if need an example). In my first example clearly the image is from 2014 and not 2023. How do we know? We look at multiple tags and for the earliest.

The second part is to make the experience easy for the user. It may take a small extra step, but it really isn't much work and the benefits compound. You can expose the other unique dates to the user as options instead of requiring manual selections (have both!). This should also help them report more easily. Think of it this way, everyone hates when you have a dropdown box on a website that asks you for your country and it is all just in alphabetical order. Yet we as programmers know we can have that sorted list, read the browser's country, and place that item at the top (it is seriously absurd that this feature is not common on websties...).

Clearly there's a problem and it isn't between the keyboard and chair. If there is a problem with what was proposed the issue is a great way to get other users involved and find a better working idea. But the current solution is broken since the problem is more complex than the solution can handle.

@stevenwalton commented on GitHub (Sep 1, 2024): @alextran1502 is there something wrong with [what I proposed](https://github.com/immich-app/immich/issues/5164#issuecomment-2227835814)? I do not think this is an issue that can be solved by using a preferential list of Exif dates. Think about how we humans can determine the actual date from the reported Exif data (see mine if need an example). In my first example clearly the image is from 2014 and not 2023. How do we know? We look at multiple tags and for the earliest. The second part is to make the experience easy for the user. It may take a small extra step, but it really isn't much work and the benefits compound. You can expose the other unique dates to the user as options instead of requiring manual selections (have both!). This should also help them report more easily. Think of it this way, everyone hates when you have a dropdown box on a website that asks you for your country and it is all just in alphabetical order. Yet we as programmers know we can have that sorted list, read the browser's country, and place that item at the top (it is seriously absurd that this feature is not common on websties...). Clearly there's a problem and it isn't between the keyboard and chair. If there is a problem with what was proposed the issue is a great way to get other users involved and find a better working idea. But the current solution is broken since the problem is more complex than the solution can handle.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
accessibility
changelog:enhancement
changelog:security
changelog:translation
cli
date-time
documentation
external-library
format
good first issue
needs-answer
nice to have
sharing
tech-debt
📱mobile
🖥️web
🗄️server
🧠machine-learning
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#1653
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?