Replies: 21 comments 117 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.
-
|
Even without it I will be able to tell if it will fallback to a default timezone or not, so it doesn't really matter IMO. |
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.
-
|
For future reference (possibly useful to others in this thread), I discovered that it appears timestamp data can be preserved with 7zip by using the 7z format (zip does not have created date as a field at all), and putting the additional parameters "ta tc" into the 'Parameters' field in the compression dialog. |
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.
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.
-
Beta Was this translation helpful? Give feedback.
-
|
I think you're confusing "when" and "where". Just set coordinates if you care about the "where". |
Beta Was this translation helpful? Give feedback.
-
|
Here's me in Chile: |
Beta Was this translation helpful? Give feedback.
-
|
And here's me in NYC: |
Beta Was this translation helpful? Give feedback.
-
|
@jrasm91 @C-Otto Here is one of the problematic picture. Look at "Gps Time Stamp", "Create Date" and file name. Thanks to this information you can tell it is 12:35 UTC+1 (CET). And for some unknown reason: I've noticed this on the problematic pictures I checked. Not all pictures from this Moto G6 have this particularity and maybe this confuses immich. |
Beta Was this translation helpful? Give feedback.
-
|
@C-Otto in this case it is not sharing (I did not test this use case though). |
Beta Was this translation helpful? Give feedback.
-
|
I have launched a full metadata extraction job. Let's see if it fixes the problem. |
Beta Was this translation helpful? Give feedback.
-
|
No change after full metadata extraction job, still bad time @C-Otto |
Beta Was this translation helpful? Give feedback.
-
|
Hello @C-Otto and @jrasm91 |
Beta Was this translation helpful? Give feedback.
-
|
Bug report submitted #14087 |
Beta Was this translation helpful? Give feedback.
-
|
I have a number of images with wrong timezone set in-camera. Immich shows datetime and timezones as set in camera. Due to wrong timezone images incorrectly sorted in the Immich timeline. I'd like to fix wrong timezone in images. But looking at exiftool output for correct (2024-10-05 17-46-36.JPG in-camera timezone +3) and wrong (2024-10-19 14-16-15.JPG in-camera timezone +4) images I can see NO difference - system and maker's both timezone set to +3 and DaylightSavings to Yes. What image 2024-10-19 14-16-15.JPG tag should I correct for Immich to see it as correct +3, not wrong +4? .env Daylight Saving TimeEEST: Eastern European Summer TimeCurrently in use | UTC+3 Images pack !!!Deleted on update as not related!!!
and their exiftool times: |
Beta Was this translation helpful? Give feedback.
-
|
Did some research and found out the answers. There were actually two problems.
|
Beta Was this translation helpful? Give feedback.
-
|
Image: Christmas Tree |
Beta Was this translation helpful? Give feedback.
-
|
Here is another example but I am not going to zip it,
Here is the meta data I see pre-zip
Then, after zip/unzip, i see this:
Which leads me to believe, something is getting lost in the zip/unzip. Which, to be fair, I have never heard of a Zip modifying data like that. |
Beta Was this translation helpful? Give feedback.
-
|
Here is that file zipped for your reference |
Beta Was this translation helpful? Give feedback.
-
|
Here is the metadata viewer I am using https://pics.io/photo-metadata-viewer |
Beta Was this translation helpful? Give feedback.
-
|
Try using https://exif.tools/ (or just actual exiftool on your system) instead, so you're using the same tooling that Immich is. |
Beta Was this translation helpful? Give feedback.
-
|
zipping a file will not change the metadata as that is stored in the binary file data itself, but it WILL mess with the file dates (normally stored in the file system not the file). specifically, the 'created date' does not get stored in a zip at all. see my post above: #12650 (reply in thread) for more info. |
Beta Was this translation helpful? Give feedback.
-
|
I have some timezone oddities trying to move my ~20k asset library into Immich. I am in CEST +2:00/+1:00 depending on DST, which is where most of my photos are created. Except my current phone, Pixel 7, all my media show up 1 to 2 hours (depending on DST) ahead of where they should be, while still detecting and displaying the timezone correctly. My older phones are Pixel (1), Axon 7, Nexus 5, all the way back to a Sony Ericsson W595, and digital cameras. I manually added timezone info to the digital camera and "dumbphone" photos with Exiftool, and now they behave the same. It's like the time was interpreted as UTC and the timezone offset was applied on top of it. Example EXIF data from a Pixel 7 photo that works correctly: Showing up correctly as 2023. máj. 26. P 22:01 GMT+2:00 Example EXIF data from a Pixel 1 that does not work correctly (this one has untouched exif data) Showing up incorrectly as 2023. máj. 26. P 23:11 GMT+2:00. This photo shows a clock at 21:11 and was taken before the previously mentioned, I took both when I bought my new phone. I am fairly lost at what could be wrong. I uploaded each of my asset with immich-go. I attached both of the example photos. I have another unrelated issue too, I have some old camcorder / digital camera video recordings in .mp4, .avi and .mpg files. I cannot see any time related metadata on them, with exiftool, avi metaedit, or various file managers and video players. Even if there was, it should be months off, as I know time was not set correctly on these devices and file creation dates were off by months. I adjusted file creation dates with NirSoft's bulk file changer to line up correctly. When I upload these files to immich, they get converted to UTC, correctly, so they receive UTC as timezone info and are 2 hours earlier than my local timezone they were recorded in. I have seen a flag in code which would suggest this is intended, but why convert to UTC when it looks like there is timezone info available (judging from how it made a correct conversion in my case)? Is there any way to convert photos to a given timezone, without adjusting the clock and timezone one by one? |
Beta Was this translation helpful? Give feedback.
-
|
On my server the Pixel 1 photo (IMG_20230526_211114.jpg) shows up as 21:11 GMT+02:00, which I'd say is correct. I'm using v1.120.1. The other photo also shows the correct time (22:01 GMT+02:00). |
Beta Was this translation helpful? Give feedback.
-
|
You're right. Looks like it was a mistake from me to assume Immich-Go doesn't mess with the timestamps and it's handled on the backend entirely, it very much does; uploading the same file from immich-go and the web UI results in a difference in how times are handled. I'll take my issue to their repo. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Hello,
|
Beta Was this translation helpful? Give feedback.
-
|
The photo has been taken on an iPhone at 19:01 CET in Paris, France. It is shown like that in Lightroom, and based on that the Lightroom export has also put the time in the filename. ExifTool also shows 19:01: But Immich puts the file at 18:01: I have tried to set the TZ env variable, but that does not change anything. |
Beta Was this translation helpful? Give feedback.
-
|
As also visible on your screenshot, the OffsetTime is set to +01:00. Do you know where this value came from? |
Beta Was this translation helpful? Give feedback.
-
|
I further investigated and played around, and it looks like indeed actually Lightroom messes that up, not Immich. I just did not have this situation before. So it is obviously a bug in Lightroom. There is also a very old discussion here, where someone mentions it would be resolved in the current version, but it isn't :-( So this is not directly an issue of Immich, but an issue with Lightroom in the situation where picture was taken in summer time but export was done in winter time. Bad Adobe! |
Beta Was this translation helpful? Give feedback.
-
|
After reading a bit more, I think that it actually is an issue with Immich. |
Beta Was this translation helpful? Give feedback.
-
|
This is data provided by exiftool-vendored, photostructure/exiftool-vendored.js#220 |
Beta Was this translation helpful? Give feedback.
and others
-
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