Replies: 103 comments 257 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.
-
|
zip file (of one effected file) is attached. All of the effected files are .mov like that time it should have is 2015-07-14 08:37:26+02:00 |
Beta Was this translation helpful? Give feedback.
-
|
someone posted above from the source code: immich/server/src/services/metadata.service.ts Lines 35 to 50 in bbfff64 CreateDate and MediaCreateDate seem to have higher priority than CreationDate, and are also present in your file, so your wrong date is coming from CreateDate (i think that's "Kodierungsdatum") a quick fix would be to change CreateDate to match CreationDate or maybe CreationDate should have higher priority, from what i understand it is a quicktime specific tag, i'm not sure if that means it is always 'more right' than CreateDate when present, maybe someone with more experience can tell us that |
Beta Was this translation helpful? Give feedback.
-
|
Weird one, i even have a fix, but i don't understand it: expected date: date displayed: zip: before: the fix:
after: EDIT:
|
Beta Was this translation helpful? Give feedback.
-
|
UPDATE: first, some more tags that were masked by duplicates: now, a new "fix":
the result:
interpretation:Immich seems to take the Date/Time from Exif:DateTimeOriginal and combine it with the Offset (only the offset) from xmp:CreateDate, which is a different date, and can therefore have a different timezone. -> i think this is a bug (i made a bug report but was asked to post here, so i updated this post instead) |
Beta Was this translation helpful? Give feedback.
-
|
Question, asking here because the corresponding bug report is closed: I have a few thousand pictures mis-sorted due to this issue. I was kind of hoping it would be fixed in time for stable (it's my parent's library which i would like to keep on stable). Should i expect something like this to still be fixed in a stable sub-release? (or would it be considered breaking, since it changes displayed dates?) The reason i ask is because otherwise i'll consider workarounds, but i'd rather not manipulate all the files if a fix is around the corner... |
Beta Was this translation helpful? Give feedback.
-
|
Hey, File in Immich: exiftool 2.JPG Airdropped File: exiftool 2_airdrop.JPG |
Beta Was this translation helpful? Give feedback.
-
|
you did not mention what date immich shows. |
Beta Was this translation helpful? Give feedback.
-
|
All my assets have correct time in Immich, but wrong Time zones (original is +03:00) in several cases: Videos are usually fine in the web, but in an app (iOS) they all have phone time zone. Video metadataPhotos have server time zone in the web and phone time in the mobile app. Photo metadata |
Beta Was this translation helpful? Give feedback.
-
|
i had a look only at the photo: from https://www.cipa.jp/std/documents/download_e.html?DC-008-Translation-2023-E:
-> maybe someone can confirm this but i think this is a bug |
Beta Was this translation helpful? Give feedback.
-
|
Your assumption seems correct for the web, but doesn't explain phone time zone in the iOS app. |
Beta Was this translation helpful? Give feedback.
-
|
I experience the same problem for iOS app, where it can only show time in the timezone of the phone. I think it's a bug of the app. |
Beta Was this translation helpful? Give feedback.
-
I found a SOLUTION for my video casesnote:using example times issue:locally on my Mac Apps correct time and zone displayed: good vs bad videos:checking the differences between video files that worked and ones that were wrong I found a missing metadata tag make sure you have the right offset at the end eg: solution(assuming -3 timezone delta for you) other things to trycheck your docker containers date is correct (assuming make sure XXX is the correct timezone. If its wrong, check your servers timezone config, and check that its properly set in your docker container. |
Beta Was this translation helpful? Give feedback.
-
|
i think i found a real issue: Immich combines dates/times with timezones/offsets from different tags that are not supposed to go together in #12650 (comment), DateTimeOriginal is combined with the offset from CreateDate in #12650 (comment), DateTimeOriginal is combined with OffsetTime which is also the wrong combination (see my reply) Unless someone points out a flaw in my reasoning i will go ahead an make a bug report EDIT: |
Beta Was this translation helpful? Give feedback.
-
|
Posting here based on advice given in different thread for different issue, pointing to this thread for ALL date/time related issues. Running immich v1.140.1 in a docker container on an ubuntu 22.04 desktop distro. Images are:
My issue is that a lot of my images are being shown on their file-modified date, instead of creation date, in the example below they are shown on Today's date 2025:09:08, instead of when they were taken/modified [DateTimeOriginal] = [ModifyDate] = 2016:05:15 10:48:56. [ExifTool] ExifToolVersion : 13.34 
This seemingly affects everything I change, as when I tried writing DateTimeOriginal tag to a large batch of photos at once, to make sure they had the proper and same EXIF tag, they all moved to todays date in Immich, after I did a complete refresh of all my image metadata. I can replicate it easily, by editing photo dates using Synology Photos for example, which sets DateTimeOriginal + Modifydate to what I state it should be - but of course also changes the FileModifyDate tag to todays date + time. When going into Immich, photo is shown on "today". Attachment: |
Beta Was this translation helpful? Give feedback.
-
|
I seem to have exactly the same issue with a lot of my assets. Extracting metadata briefly fixes the sorting in the timeline, and very quickly after that another job moves them back to their modification date places in the timeline, messing everything up again. If you (of anyone else) has a fix for this, I'd be happy to hear about it. If anyone needs more information/metadata, let me know and I'll post that. |
Beta Was this translation helpful? Give feedback.
-
|
The new v1.141.1 update should fix this issue. Be sure to update to the latest version on both the server and mobile, delete the affected assets from the server, and try to upload them again, with metadata extraction. |
Beta Was this translation helpful? Give feedback.
-
|
I just tried updating and while indeed, many photos were moved to correct, dates, some still remain on the wrong dates. Example: [ExifTool] ExifToolVersion : 13.34 
Attached: Notes:
Hence I cannot perform " delete the affected assets from the server, and try to upload them again, with metadata extraction.". |
Beta Was this translation helpful? Give feedback.
-
|
Update: With V2.0.1 I the "refresh metadata" button works and it updates the selected photo correctly. I no longer need to delete the photo. @magnusbjarnason I ran into a similar issue. It seems that metadata is only extracted on first scan. Even removing the external library path and then adding again wouldn't update the metadata. It seems that removing the external library path only hides the images, but doesn't really delete all associated data. What worked for me:
After doing so, the images in Immich were created again, but this time with the most recent metadata. |
Beta Was this translation helpful? Give feedback.
-
|
#22002 as my issue posted here. HEIC files are parsed as having an INCORRECT default TIMEZONE（all UTC）
Although I can perform batch time offset conversion through the web interface, I need to search for problematic photos and perform operations after each backup, which is very cumbersome and prone to errors. I still hope to solve the problem of missing time zone information for photos in HEIC files, because there is no problem with the time or sorting displayed in the default album or other app on iPhone. Thank you. |
Beta Was this translation helpful? Give feedback.
-
|
The mobile app follow the system time zone you set on your iPhone, rather than the actual time zone, affecting both Android and iOS/iPadOS I have tested this extensively, and it is definitely a mobile app issue. Whether the photo was taken on the phone or downloaded from elsewhere, the app ignores the time zone stored on the server database or embedded in the file and always displays the timestamp using the phone’s time zone. Anyone can repeat this bug by:
|
Beta Was this translation helpful? Give feedback.
-
|
I confirm, I had opened an issue to try to explain the problem, but I am having difficulty doing so because it has been closed. ( #22341) |
Beta Was this translation helpful? Give feedback.
-
Peak GitHub Discussion incoming |
Beta Was this translation helpful? Give feedback.
-
|
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.
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