Replies: 112 comments 262 replies
-
|
Can we also ask people to include their .env with the TZ variable and the output of |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
Please have a look at #5897. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
so no fix :( |
Beta Was this translation helpful? Give feedback.
-
|
Adding my old issue #9331 to here ... (no need to duplicate info, right?)
|
Beta Was this translation helpful? Give feedback.
-
|
You post is quite large actually. Can you post exactly:
|
Beta Was this translation helpful? Give feedback.
-
|
Updated my comment.. |
Beta Was this translation helpful? Give feedback.
-
|
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:
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. |
Beta Was this translation helpful? Give feedback.
-
|
The second point should be addressed with #12779 |
Beta Was this translation helpful? Give feedback.
-
|
#9331 was just closed by @danieldietzler . |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I also have a lot of photos misplaced in my timeline. Those photos are old photos from external libraries. Some photos from Google Takeout does not have any useful metadata. IMG_20130913_081540.JPG: PANO_20170416_105856.jpg: Metadata: CameraZOOM-20150715115510237.jpg: IMG_20151222_135145.vr.jpg: |
Beta Was this translation helpful? Give feedback.
-
|
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:
|
Beta Was this translation helpful? Give feedback.
-
|
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: Immich's Coordinates after import I did search for the issue but couldn't find anyone else reporting it
|
Beta Was this translation helpful? Give feedback.
-
|
Hey. This thread is about timezone/timeline issues - but I suppose incorrect GPS can affect where the images shows in a timeline. |
Beta Was this translation helpful? Give feedback.
-
|
Sony dslr-a550 a zip of your file: DSC09740.ZIP |
Beta Was this translation helpful? Give feedback.
-
|
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.
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
|
as requested, posting my experience over here as well. Immich displays a lot of my images and videos in the wrong date in the timeline, and in the incorrect timezone. for example: this also happens with most videos: 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: Attaching both a zip of the video: and the image: |
Beta Was this translation helpful? Give feedback.
-
|
Upgraded to Immich 1.118.0. 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 |
Beta Was this translation helpful? Give feedback.
-
|
Did you rescan the metadata for those files? |
Beta Was this translation helpful? Give feedback.
-
|
I ran extract metadata on all twice |
Beta Was this translation helpful? Give feedback.
-
|
to provide an update: the incorrect positioning for videos without metadata (but correct file attributes) is still present in current immich (v1.120.2).
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
If you want me to look at anything you need to do the following:
|
Beta Was this translation helpful? Give feedback.
-
|
me too..... |
Beta Was this translation helpful? Give feedback.
-
|
@C-Otto Hello, here's my question |
Beta Was this translation helpful? Give feedback.
-
|
This image does not contain any timezone information. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
@jrasm91 maybe you can chime in? |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
This is just bad metadata, you should fix the file. |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
I'm pretty sure, yeah. |
Beta Was this translation helpful? Give feedback.
-
|
Worked 100%. Thank you! |
Beta Was this translation helpful? Give feedback.
-
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
date is correct, but the two hours offset of the timezone are falsely deducted
|
Beta Was this translation helpful? Give feedback.
-
|
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). |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
@C-Otto Can a setting option be implemented to freely choose whether exif is offset from the time zone? |
Beta Was this translation helpful? Give feedback.
-
|
@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). |
Beta Was this translation helpful? Give feedback.
-
|
Refreshed metadata and looks good now. Thanks @C-Otto |
Beta Was this translation helpful? Give feedback.
-
|
ok, i'm now having more bizarre behavior. here's a zip with photos 1975 metadata: 1990 metadata: the end result in my timeline is that 1975 is totally correct. it appears under however -- 1990 appears under 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 |
Beta Was this translation helpful? Give feedback.
-
@C-Otto I'm using the timezone setup from the official docker-compose.yml: On the docker host: |
Beta Was this translation helpful? Give feedback.
-
|
@lgrawet can you upload a sample file, and extected vs actual expectations in a new top level comment? |
Beta Was this translation helpful? Give feedback.
-
@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 |
Beta Was this translation helpful? Give feedback.
-
|
Which time should be shown, though? Currently, it's the local time converted to UTC (i.e. two hours off for me). |
Beta Was this translation helpful? Give feedback.
-
|
Which file? |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
I agree with you in theory @alextran1502 but there is currently no good way for users to know which assets require this pre-ingest cleanup. We don't have any option such as "ignore missing timestamp" for CLI or web upload. |
Beta Was this translation helpful? Give feedback.
-
|
@LittleNewton - sure, but it's not obvious what/how to do about it and it also isn't trivial to fix either. I'm not saying we won't ever fix it, but that's the current state of things. Thank you for bringing it up and we will update this thread when we have a solution or resolution that problem. |
Beta Was this translation helpful? Give feedback.
-
|
Hi jrasm, I have update to v1.118.1 and the time zone is still wrong. Please derive a right timezone from GPS if there is. import pathlib
import os
import datetime
imageFolder = 'img' + '/'
File_List = os.listdir(imageFolder)
for picture in File_List:
# get main name
filePath = imageFolder + picture
fileName = pathlib.Path(imageFolder + picture)
creationTime = str(datetime.datetime.fromtimestamp(fileName.stat().st_ctime))
baseName = ''
for char in creationTime:
if char != ':':
baseName = baseName + char
# get extension name
newName = imageFolder + baseName + '.' + filePath.split('.')[1].lower()
os.rename(filePath, newName)I never use the upload functionality inside of immich because I trust my NAS's smb service more than a app and I believe there are a lot of human have the same opinion. Before I moving the photos to immich's external directory, I will use this python script to renaming them. |
Beta Was this translation helpful? Give feedback.
-
|
This python code can derive the exact right SAVED TIME for pictures saved on your phone. The SAVED TIME is the time you save this picture from ins/x/whatsapp to your phone, not the time you press the shutter. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
After so many time, I really don't understand why TZ is considered only if "DateTaken" or GPS coordinates are present in the file... So it doesn't works for any non-jpeg or any WhatsApp (for example) image. |
Beta Was this translation helpful? Give feedback.
-
|
zip: photo.zip Immich v2.0.1 (Windows Desktop Docker) This happens to every image that has no time zone information. Does this work as intended? Is there a solution? |
Beta Was this translation helpful? Give feedback.
-
|
I believe I am seeing the same issue that @lisauporoten-commits mentioned here: #12650 (comment) Photos with no date information... I downloaded a photo from Discord app to my Recents album (iOS), and the metadata had been stripped by Discord. This photo was automatically uploaded to Immich as it should be. When viewing the image in Immich web, it put the datetime as 6 hours ahead of what it should be. (My UTC offset is -6 hours). This issue is much easier to notice when the difference spans midnight: this image was downloaded at 11pm in my timezone, (-6 from UTC). It shows in the Immich Web timeline as being 5am the next day, which is unexpected (it should show as 11pm in expected day). It shows on Mobile timeline (the device I used to upload it to immich) on the correct day and correct time. It also shows on the correct day and time in the Immich App on my partner's iOS device (a device that does not have the image downloaded locally). My immich server has my timezone set to My web preferences are to use the default locale, which appears to be using the correct times for my timezone. Update: Per this comment, it seems iOS app is using the correct date despite the server's dates. I looked in the postgres db and found the following: For images uploaded with proper metadata (images taken on my iOS device), when I look at the But, when looking at the offending images (the ones which I downloaded from Discord and as such, the metadata was stripped), all of the above timestamp fields in the db have approx the same time and timezone, including the Comparing the files with metadata and the files without, I am guessing that this means that the offending files (the ones without metadata) actually have the wrong time set in the It is unclear how |
Beta Was this translation helpful? Give feedback.
-
|
Update: I've noticed the following: If I go into the Immich web ui Timeline and select the photo that did not have metadaa, and then choose "Change Date" option and then choose the "Change Date By Offset" option and then ONLY set the Timezone -- Ie, leave the other fields blank, then hit "confirm", then reload the page ... then, photos pop into the correct (expected) place in the timeline. (Note, if you click on the photo instead of selecting it, then when you go to change the date, you won't see the "Change Date By Offset" option, so you need to select it on the main timeline and then click the dots and to "Change Date" there) |
Beta Was this translation helpful? Give feedback.
-
the sample picthe expected date, including timezone2024-08-21 22:25:45 UTC+08:00 current date produced by immich2024-08-21 22:25:45 inside the container ✅ @bo0tzz says I should post here, so I post my issue here again as #23058 time for images without EXIF showing 8 hours earlier on the webuiI have already added /etc/localtime and even /etc/timezone in the Docker Compose configuration, and set the environment variable TZ=Asia/Shanghai (UTC+08:00) 
But in the mobile app, the time displayed is correct. This makes me think that the time stored in the database might be correct, and there could be an issue when the webui retrieves or converts the time 
Actually, this issue has persisted since version after 1.115. I had been using version 1.115 all along, which version both webui and app are showing correct time Is this a bug, or is there some configuration I haven't found yet? |
Beta Was this translation helpful? Give feedback.
-
|
This looks like it might be the same bug I mentioned in the previous comment. Note that the datetimes appear correct in mobile apps because mobile apps don’t use the server’s version of the time (another comment in this thread seems to make this point well). My personal opinion is that the datetimes of images without EXIF data are wrong in the server’s db. |
Beta Was this translation helpful? Give feedback.
-
So you mean that the reason could be that the database is indeed storing the wrong time, and the fact that the iOS app displays it correctly is precisely because of another error or feature? OMG, that's just...😂 |
Beta Was this translation helpful? Give feedback.
-
hi, bro, after the system ran the scheduled backup task, I noticed another thing. My backup settings haven't been changed from the default, which is 02:00 (2 AM). Judging from the resulting filenames, the timestamp in them is also 0200. However, the actual execution time was 10:00, meaning it ran 8 hours later than scheduled. It seems there's still something off with the timezone configuration 
|
Beta Was this translation helpful? Give feedback.
-
I agree with this! The photos that I've saved from other apps like Instagram have no metadata, so I would expect them to use the timestamp shown in IOS (dated created/modified whatever), and it does, except in the web view the time is off by four hours. I'm in eastern time so that would make sense. I have my .env timezone set to 'America/New_York' The Immich mobile app shows the correct timestamp if the original is still on my device, but if I delete the original from my device, the Immich app then adds four hours to the timestamp, presumably using the server's database timestamp which is incorrect. All of my other photos that have proper metadata are showing the correct timestamp. |
Beta Was this translation helpful? Give feedback.
-
|
I've mentioned this in my issue #23383 but since I suppose it was a duplicate (my bad) it was closed, but I feel like this might be important to this issue, so I wanted to add this bit to the discussion, so that it can maybe help move along this problem. I noticed that the API for the asset/get (getAssetInfo) endpoint has this to say about
But when I requested the asset info myself using
But that does not appear to be happening for these assets that lack EXIF metadata |
Beta Was this translation helpful? Give feedback.
-
|
I uploaded seperate zip files since github has a limit of 25mb per file. I have some photos and videos, when on device everything shows completely good, I also tested with examing raw metadata with various tools, also uploaded to google photos, apple photos, ente photos and they show the correct metadata. Even the immich mobile app shows the correct metadata when on device section. Once I upload it, they mess up the data and everything is messed up, the same photos and videos shows different time and timezone on web ui and mobile app, I tried uploading from mobile app, web ui, everything no luck. uploaded my docker-compose and env files. I have set my TZ to It's been a lot of year since this issue arised and immich is perfect and I think this is the only part that needs correction. Thank you for your work!
|
Beta Was this translation helpful? Give feedback.
-
|
Unraid docker, immich server version 2.2.3 |
Beta Was this translation helpful? Give feedback.
-
|
hello, when do you fix this bug? |
Beta Was this translation helpful? Give feedback.
-
|
I understand why open source maintainers burns out. You could use some kindness, since this is not a service you're paying. And even if you paid it, that's not the right way. |
Beta Was this translation helpful? Give feedback.
-
|
When you develop a fix and push it. |
Beta Was this translation helpful? Give feedback.
-
|
The field 'fileCreateTime' got from filesys fs.stat api, which is a syscall, in a linux terminal, this create time shown as 'Modify: 2025-03-21 19:52:13.000000000 +0400', and its saved time as '2025-03-21T13:52:13.000Z', so server modele works well. |
Beta Was this translation helpful? Give feedback.
-
|
A photo sent to me has exif fields with proper data but for some reason immich uses FileModifyDate which is the date the file was actually sent to me via Telegram. The file is in the external library. |
Beta Was this translation helpful? Give feedback.
-
|
Here's my contribution. This is one of several our daughter sent us via WhatsApp shortly after having taken them, so the WA time stamp should be within a few minutes of the time stamp on the actual image on her phone - I'm not worried if their off by a few minutes, but they're off by a couple of months! Date/Time as shown by Immich: Actual Date: 2025-07-29 12:36 + 0100 (GMT+2) EDIT: (corrected from GMT+1) -- Note minutes are approximate - that's when I received it via WhatsApp - if that's the closest you can extract, I'm 100% great with that. Her phone (or WhatsApp) doesn't seem to include a time stamp in the filename. |
Beta Was this translation helpful? Give feedback.
-
|
I've been grappling for some time with Immich showing the wrong timezone on photos taken on a DSLR set to GMT in Kenya (GMT+03:00) with the GPS location added from a trackfile. I thought I had it sussed by using exiftool to set the timezone but, while exiftool reported TimeZone="+03:00" Immich was displaying "GMT+04:00". Tried several times to change the timezone in exiftool and Extract Metadata in Immich, to no avail. When I asked exiftool for -time:all I realised there's a Daylight Savings option (Yes/No) which was set to Yes. That would explain the discrepancy... Might be helpful to someone else in the same boat. Is it possible to Extract Metadata for a subset of files? (I'm using External Libraries and it take quite a while to rescan the whole lot when I'm resolving individual folders). |
Beta Was this translation helpful? Give feedback.
-
|
I've been using Immich for awhile now and yesterday on the eve of the big planned family Immich migration I noticed a discrepancy between the time/date shown in the web interface (correct) vs the Android app (one hour in the future). :( As requested a test photo: The expected date+time: Before uploading to the server the phone shows 08:46 After uploading/syncing to the server the web interface shows 08:46 After uploading to the server the phone shows 09:46 I hope you guys can tell me what's wrong. I use Immich on my TrueNAS. The time in the docker container is correct: The Immich TZ variable is set to Europe/Amsterdam. My phone is in the same timezone (shows as GMT +01:00 in the Android settings) |
Beta Was this translation helpful? Give feedback.
-
|
For the record, with the file in this zip: |
Beta Was this translation helpful? Give feedback.
-
Hi, is this helpful info for the devs, or were you trying to inform me of something? I have absolutely no clue what's going on here/why Immich is behaving like this. I've never seen this behavior with the evil cloud services I've been using before. |
Beta Was this translation helpful? Give feedback.
-
|
I have written a rough tool that people hit with this issue might find useful: https://github.com/fizbin/immich-tz-fixer It changes the timezone on immich assets to match a given timezone, and can also reset the second and sub-second parts of an asset's time if you have the original file and that file has within it fine-grained time metadata. It is not a tool I want to make easily available yet, but if you're comfortable with the command line and Please do not use the tool without using the |
Beta Was this translation helpful? Give feedback.
-
|
Expected：2025-12-09 18:54 ⸻ Immich iOS 2.3.0 A screenshot taken on iOS at 6:00 PM on January 1st gets backed up to Immich and appears as 2:00 AM on January 2nd, showing an 8-hour difference. Other Android devices on the same LAN don’t have this issue. |
Beta Was this translation helpful? Give feedback.
and others
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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:
Please post a comment in this discussion with the following, and we will happily investigate the issue.
EDIT: if you don't post the three points mentioned above, you're comment will simply be marked as off topic and hidden.
Beta Was this translation helpful? Give feedback.
All reactions