Replies: 136 comments 283 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.
-
|
TZ field in .env is not used in sorting photos for the mobile or desktop app. The 3264x2448 photo was taken with OpenCamera (which has always been a mess), the 4000x3000 photo was taken with the default Camera app. As shown on the device make and model column, enormous swathes of my current photo library are potentially affected. Valid dates, times, and orders from v1.143.0 are grandfathered in until you decide to edit metadata (such as when I enhance a blurry photo with ESRGAN). Using the first photo as an example, expected date based on old behavior: (second one not ideal, but at least it shows up in the right order) Actual behavior: Somewhere along the line, the .env timezone stopped working for its intended use. I have read the documentation and this seems to be accidental. The OS that Immich Server is running ondocker desktop on Windows 10 LTSC Version of Immich Server & Mobile Appv2.4.1 Platform with the issue
Camera makes and modelNon geotagged Fairphone 4 Android 16, Samsung Galaxy A11, iPhone 6 (iCloud link), some Google Photos downloads, photorec recovered photos, basically everything before 2015 Your docker-compose.yml content#
# WARNING: To install Immich, follow our guide: https://immich.app/docs/install/docker-compose
#
# Make sure to use the docker-compose.yml of the current release:
#
# https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
#
# The compose file on main may not be compatible with the latest release.
name: immich
services:
immich-server:
container_name: immich_server
image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
# extends:
# file: hwaccel.transcoding.yml
# service: cpu # set to one of [nvenc, quicksync, rkmpp, vaapi, vaapi-wsl] for accelerated transcoding
volumes:
# Do not edit the next line. If you want to change the media storage location on your system, edit the value of UPLOAD_LOCATION in the .env file
- ${UPLOAD_LOCATION}:/data/upload
- ${LIBRARY_LOCATION}:/data/library
- ${THUMB_LOCATION}:/data/thumbs
- ${ENCODED_VIDEO_LOCATION}:/data/encoded-video
- ${PROFILE_LOCATION}:/data/profile
- ${BACKUP_LOCATION}:/data/backups
- /etc/localtime:/etc/localtime:ro
- "_____HARD_DRIVE_PHONE_PICS_____:/files/phonepics:rw"
- "_____HARD_DRIVE_READ_ONLY_____:/files/hddpics:ro"
env_file:
- .env
ports:
- '2283:2283'
depends_on:
- redis
- database
restart: always
healthcheck:
disable: false
immich-machine-learning:
#irrelavant
redis:
container_name: immich_redis
image: docker.io/valkey/valkey:8-bookworm@sha256:fea8b3e67b15729d4bb70589eb03367bab9ad1ee89c876f54327fc7c6e618571
healthcheck:
test: redis-cli ping || exit 1
restart: always
database:
container_name: immich_postgres
image: ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0@sha256:8d292bdb796aa58bbbaa47fe971c8516f6f57d6a47e7172e62754feb6ed4e7b0
environment:
POSTGRES_PASSWORD: ${DB_PASSWORD}
POSTGRES_USER: ${DB_USERNAME}
POSTGRES_DB: ${DB_DATABASE_NAME}
POSTGRES_INITDB_ARGS: '--data-checksums'
# Uncomment the DB_STORAGE_TYPE: 'HDD' var if your database isn't stored on SSDs
# DB_STORAGE_TYPE: 'HDD'
volumes:
# Do not edit the next line. If you want to change the database storage location on your system, edit the value of DB_DATA_LOCATION in the .env file
- ${DB_DATA_LOCATION}:/var/lib/postgresql/data
shm_size: 128mb
restart: always
volumes:
model-cache:Your .env content# You can find documentation for all the supported env variables at https://immich.app/docs/install/environment-variables
# The location where your uploaded files are stored
UPLOAD_LOCATION=_____HARD_DRIVE_PHONE_PICS_____
THUMB_LOCATION=___SSD___
ENCODED_VIDEO_LOCATION=___SSD___
PROFILE_LOCATION=___SSD___
BACKUP_LOCATION=___SSD___
LIBRARY_LOCATION=_____HARD_DRIVE_PHONE_PICS_____
# The location where your database files are stored. Network shares are not supported for the database
DB_DATA_LOCATION=___SSD___
# To set a timezone, uncomment the next line and change Etc/UTC to a TZ identifier from this list: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones#List
TZ=___SET_TO_WHERE_I_LIVE___
# The Immich version to use. You can pin this to a specific version like "v1.71.0"
IMMICH_VERSION=release
# Connection secret for postgres. You should change it to a random password
# Please use only the characters `A-Za-z0-9`, without special characters or spaces
DB_PASSWORD=__________
# The values below this line do not need to be changed
###################################################################################
DB_USERNAME=_______
DB_DATABASE_NAME=________
DB_HOST=________Reproduction steps
Relevant log outputAdditional informationI struggled with whether to include this as a feature request or a bug report. I decided to do both. I will be making a feature request for a complete overhaul of time zone determination. For now, though, a core part of the timeline functionality of Immich has been broken, and I believe it was done so unintentionally. I would try to fix it soon. Cheers! |
Beta Was this translation helpful? Give feedback.
-
|
Issue remains to be screenshots being automatically uploaded to immich at GMT+00:00 when the correct timezone should be GMT+08:00. I attached here the zip of the sample screenshot: Correct time and timezone should be 7:22PM at GMT+08:00 but what ends up being displayed is 7:22PM at GMT+00:00. 
|
Beta Was this translation helpful? Give feedback.
-
|
This issue remains on Server verion 2.5.3 build 243 and iOS App version 2.5.3 and only affect screenshots and saved photos after upload. The time zone I set in server is TZ=Asia/Shanghai, which stands for GMT+08:00.
|
Beta Was this translation helpful? Give feedback.
-
|
Issue 24382 was raised separately as this issue still persists, but it was closed. I have commented on it to share my thoughts, but since it is closed, I don't know if anyone will check it out seriously. Is there any chance that a solution for the iOS screenshot issue to be addressed/fixed as a specific issue? Is it the development team's consensus that this is something that will/should be fixed - just awaiting bandwidth to do so? While I completely understand I don't have the full picture, it seems a relatively simple solution and one that would fix a behaviour that delivers a sub-optimal experience for many users. thanks in advance for you hard work and consideration :-) |
Beta Was this translation helpful? Give feedback.
-
|
Cheers everyone, I have severely annoying issues with the sorting of images: I backed up images from my iPhone (there, in the Photos app, all images are sorted neatly according to what equals the "Create Date"). In immich, they are sorted differently (i.e. images with timezone are shifted wrt. the images without timezone information). The images are from multiple sources (iPhone, "normal" camera) and some have timezone information, others don't. I manually stripped all timezone / gps time information from an example file and re-ran the "refresh metadata", assuming that timezone information would be stripped from the immich-stored metadata but without success. What is also weird, is that the image files themselves do not store any timezone information from which the data that immich stores could be inferred. I assume it got plugged on top of the metadata by the iPhone backup?!? long story short:
kindly, |
Beta Was this translation helpful? Give feedback.
-
|
I have similar issue but only with some of the videos. These videos just get random date time assigned (with the offset for couple of years in the past or future). |
Beta Was this translation helpful? Give feedback.
-
|
Cheers everyone, here is a follow up on the previous message. Unfortunately I must say this is utterly annoying and weird behavior and I can't really wrap my head around whats happening! I uploaded a new test file (something I just captured... in my camera (a Fuji) I set my home timezone to UTC+2). It shows the capture time as: 
Then I change the timezone to UTC 
one could assume that now the timezone setting of that image is changed, however, Immich shifted the "capture time" of that image and still displays GMT+2 
also, it created a XMP sidecar file for that image from this I would assume that the displayed Timestamp for that image is 22:23:10 (without timezone, or UTC, but not GMT+2). Refreshing the metadata for that image doesn't do anything. I also ran the "Sidecar Metadata" job from the admin panel (this also triggered the "Extract Metadata" job). But this also did not change a thing. I assume that metadata is stored in the database and does not get updated when refreshing the metadata / or some part gets updated and things get mixed up. If I have time I will poke the Postgres db a bit to provide more information. My first instinct was to set the timezone to UTC for all images and have them displayed at their saved capture time, solving the problem of misaligned images taken with different cameras (and different in-camera settings). There are also other things I discovered (not sure if I should open a issue for these?):
Let me know if I can provide any additional debug information cheers, |
Beta Was this translation helpful? Give feedback.
-
|
Further information on this: Updating the TimeZone does not update the TimeZone in the DB.
Is this a bug or expected behavior? is there any way to actually update the TimeZone value in the DB? |
Beta Was this translation helpful? Give feedback.
-
|
I have been experiencing this issue with timezone/date. |
Beta Was this translation helpful? Give feedback.
-
|
We updated to version 2.5.5, but the problem persists. |
Beta Was this translation helpful? Give feedback.
-
|
Just updated to 2.5.5 on Server and Android App (Fairphone 4 with GPS disabled, so no full TZ info written to exif) and still facing the same issue. Just tested with sync disabled in the Android App. The photos are correctly tagged as |
Beta Was this translation helpful? Give feedback.
-
|
I have a timezone issue which I don't see documented there. I have the same video file in an mp4 container with very complete metadata including all timezone information, and even location data. When uploaded using the web interface, the file displays with the correct time and displays correctly in the timeline. When this byte-indentical image is added via external libraries, the modification date is preferred. I have absolutely no clue why. Date/Time Original is usually the exif field that should be preferred for such things in order to accommodate for edited videos, edited photos, or even film scans. When I edit the time of the file in the web interface, the date and time listed change, but the position inside the timeline do not. I have seen others document this issue. The external library is not read only. The exif is as follows: |
Beta Was this translation helpful? Give feedback.
-
|
This should show 9th February 2026 16:14 but it’s showing 08:14 in Immich. |
Beta Was this translation helpful? Give feedback.
-
|
When uploading to Immich via the Android client or web interface, the server apparently incorrectly interprets the item's timezone. This only seems to happen for items which do not have their own EXIF data - ie. ostensibly anything that was not taken with an actual camera: screenshots, most image downloads from the internet etc. The result is that items are sorted incorrectly on the timeline in the client UI, and also display a different timezone in the info section on the UI, compared to assets this issue does not occur on. All clients I am uploading from have a consistent and correct time & timezone: The item, when initially detected by the Immich app, shows the correct timezone in the UI briefly before it is uploaded to the server. As soon as it is uploaded to the server, its timezone gets messed up or disregarded somehow and as a result it gets stored with a very different datetime than it should. I believe this is an actual import/parsing issue occurring when the server first processes the asset. In the example below, the row outlined in red (ID: 
You will notice here by the way that both items above have Regardless: the fact that only one of these values has been converted to local time and the other hasn't, suggests to me that the cause of this issue has something to do with that column's value being set incorrectly in initial processing. Both assets attached in ZIP. I have renamed them to reflect the above UUIDs and to make it clearer which one is the problematic one. Environment details:
|
Beta Was this translation helpful? Give feedback.
-
|
I just uploaded pictures from a camera and realized it showed up in a random timezone after upload. The server timezone is CET (UTC+1 right now) and i checked inside docker to be sure it is CET too.
The timezone and time is correct on the camera. (Europe/Paris) But when uploaded to immich it shows UTC-4 We can see that no timezone is available for the "Time Stamp" nor "Time Original" only for the file access screenshot in immich right after upload original file: |
Beta Was this translation helpful? Give feedback.
-
|
I observed that same issue for the pictures taken with my Panasonic camera, just like yours. As you cannot just remove one attribute of this custom structure and it is not easy to rewrite it, I completely remove it (yeah it is drastic and might not satisfy everyone) to "fix" it (then it get back to the default behavior where Immich see a picture without timezone and does not apply the TZ value, which the case I wanted to report here, but found in the next comment): |
Beta Was this translation helpful? Give feedback.
-
|
2 Photos i took within minutes with the same phone are sorted in the wrong order: 2 Files: expected dates: Dates displayed in Immich: ...which is correct, however, the images are sorted in the wrong order. shouldn't an image with no TZ information be treated as local time, i.e. +1 in my case? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, GPS section does contain timestamp that will take precedance, you can investigate this with exiftool:
This is what we all expect, but unfortunately it doesn't seem to be the case ... |
Beta Was this translation helpful? Give feedback.
-
|
Once upon a time, it actually worked. |
Beta Was this translation helpful? Give feedback.
-
|
I originally made a pretty convoluted post that got buried without reply but eventually figured the issue out myself, then i made i bug report where i was referred back here, hence this post. File: Expected Date: Date displayed by Immich: TZ in .env: Explanation: I would be happy about any feedback, and be it wontfix or that it's not a priority because admittedly the case is a bit exotic |
Beta Was this translation helpful? Give feedback.
-
|
I don't think this is a very exotic use case. I have thousands of Film Scans which reflect more or less the same issue as you have here. Rather frustrating, but what would help is if Immich had documentation on the right metadata formatting to get the desired results. |
Beta Was this translation helpful? Give feedback.
-
|
Yet another report for probably the same issue as the few ones above. I did a docker exec to immich_server and immich_machine_learning and verified that the timezone is properly set the same: (that is correct currently in Winter for Europe/Paris, we are in CET = UTC+1, then we'll later go to CEST = UTC+2) Almost all my devices (smartphone, camera, action cam) save the time in the "current location natural time", without specifying the new EXIF tag OffsetTime, OffsetTimeOriginal, OffsetTimeDigitized. Now Immich show it as Sep. 08 2020 at 17:19:28 UTC. Clicking on the set icon displays Africa/Abidjan (+00:00). Immich is clearly not using the TZ variable to apply it to pictures that doesn't have an explicit timezone set. The described behaviour above is exactly what we should have, and this is exactly what Exiftool does. I'm using now exiftool inside a Perl script, set format to "YYYYMMDD_HHMMSSz" (notice the z at the end), set the TZ and make a getValue for the CreateDate, it will return 20200908_171928+02:00. Exiftool is determining the timezone from the environment, despite the EXIF not containing the offset value in the dedicated tag, it is adding the correct one automatically. I think this is really a very common situation (if not "the most common"), I know very few devices that put the Offset tag, also most people are on a different timezone than UTC, so this must impact almost everyone. It is strange that this issue is still present? @jrasm91 WDYT? |
Beta Was this translation helpful? Give feedback.
-
|
These issues seem to be a result of a mismatch between the EXIF spec and the immich data model. For example, the immich asset schema for DateTimeOriginal is defined as a 'timestamp with time zone' whereas the EXIF spec does not allow timezone for that tag. So immich is often making the wrong assumption about what the timezone really is. I travel and take photos in many different timezones with older cameras that don't store timezone in any of the EXIF tags. Most photo management software respects this and leaves timezone as unknown. But due to the schema mismatch, immich insists on assigning a timezone and picks 0 offset by default. If immich did use your system TZ offset, it would only be correct for photos taken in that timezone. It would be better if immich waited until it knew more about our photos before forcing a timezone. But right now, if I manually add a location using the immich UI, instead of correctly setting the TZ based on the supplied location, it changes my displayed photo time by an offset equal to the new timezone. This is completely wrong and so I then have to manually modify the capture time to put it back to what was originally correct in the photo metadata. Frustrating! |
Beta Was this translation helpful? Give feedback.
-
|
It has to know about timezones in order to put all of your photos into an order. I love timeline-based viewers but they're rigid about order. I don't know how any of your other software dealt with your problem. I know Microsoft Photos just... doesn't, you choose the order inside a folder and photos respects it. That's the only way I've ever used it anyway. I'm sure Google Photos imposes the timezone from your upload location, IDK about apple. I don't travel much so I wouldn't know. The way it worked before was better than nothing. It's a shame they broke it, but really there needs to be a solution that creates a stable timeline regardless of location. I've described a system that would suit the needs of people who travel a lot. I made a feature request that would be a long-term solution to our problems, you would rarely have to enter the data in at all regardless of where you took the photos. You can check it out here: #25516 P.S. I don't like manually adding dates and times to my photos. My main hard drive has a really large block size and I don't like cluttering it up with small text files. I just use mobile exiftool to add timezone manually, maybe I'll set up tasker (I don't want to pay for software if I'm just going to root the phone later tho)... When I did, it was a real pain in the a because it treated everything as if it was formatted in utc-0 like videos or filesystem dates. |
Beta Was this translation helpful? Give feedback.
-
|
yann117 You are not crazy. I'm almost sure that Louis Rossmann is struggling with these same problems. This needs to be sternly but respectfully brought to the developers' attention. |
Beta Was this translation helpful? Give feedback.
-
|
Wow... latest problem is totally random, some times it likes the GMT offset from the camera (open camera on lineageos) and some times the GMT offset is just simply missing. firmly scrambling my day time timelines. This is worse than it's ever been. |
Beta Was this translation helpful? Give feedback.
-
|
Somebody has to write a bonafide bug report about this. And be a bit more confrontational about it than I was. I know we're supposed to post our issues here but they need to see that somewhere along the update history something got seriously screwed up. Not to be ungrateful about the software in general, but most of us are paying customers and the documentation explicitly says that photos with no offset are stored in the system TZ you specified in the .env file. This is functionality that has been broken for months. It's quite important; I would not have been able to build my library today. Not unless I downgraded to ~v1.4.2. I can't even favorite photos without a geotag or TZ without screwing up the order. I literally have to go through the song and dance of having to find a nearby photo that has a geotag on it in favorite that photo. Very often I use the favorite bar for photos that I have questions about or want to edit. One of those questions could be where was this photo taken, what was the story behind it. I really don't like having to babysit this software like that. And you're not crazy for having a setup composed of external libraries. It's not your fault. Louis Rossmann uses a setup like you do. I'm sure he gets confused and jumbled up every single day by this bug. He is probably one of the most famous people to ever promote this software. If the most famous person to promote your software is more confused after using it then they were before, I can guarantee there's a lot of people that are having problems. I'm not mad at the developers. I know that they have a really hard and often unforgiving job. Nobody praises them when they do something right and everybody dog piles when they do something wrong. But when you have developers saying that we're all experiencing intended behavior and there's no way they could have done it better. There is a way they could have done it better. I made a feature request about it (#25516). I get that it's a hard problem, though, and I would be happy, as a start, if the software just went back to following its own documentation. We need to tell the developers to their face, respectfully, that their software is not behaving within spec. I get why they shoved timeline issues into its own separate space in September of 2024 because time zones are a miserable antipattern that sucks on a good day, and metadata developers haven't done much to make it smoother. Well guess what? Your core software wasn't broken back then, and it is now. Every once in a while, you make changes that break something. I'm sure this change happened sometime in the frenzy to get stable release to market. I don't actually know because I update quite rarely, but I'm pretty sure that's when it happened. Bugs happen, but if you look away from them, instead of dealing with the problem head on, that's not how to make great software. We have to accept our mistakes and face them head on. That's how you make software that's worthy of one of the world's top 1000 most famous people. |
Beta Was this translation helpful? Give feedback.
-
|
Well ... while I still agree with all of you, the fact is that if our assets had the right EXIF tags embedded, there would be no need for applying any fix/workaround. As per the EXIF 2.31 specs (released in 2013):
On one hand it would be good if Immich devs could fix the use of the TZ variable, as this fit for a vast majority of users, having their assets belonging to their own timezone. On the other hand, I finally decided that in the meantime I would cleanup and fix my assets, as I have many images that are from other timezones and would a real correction anyway. I initially started by writing a small program that would neatly rename my images and videos according to the YYYYMMDD_HHMMSS pattern. I then modified it so that it would also create an XMP sidecar file containing the FileModifyDate. I was able to verify that this was sufficient to fix the timeline in Immich. However, I later realized that Immich’s XMP handling isn’t perfect (it rescans all media; you need to run a discovery first, etc.). Eventually, step by step, I decided to properly re-tag my images and videos by completely rewriting my script so that it handles full extraction, logging, re-tagging, renaming, and touching of files. I published it here: Sample execution: Disclaimer: Backup your library before testing/using this script !! I'm not responsible of data loss !! Use the dry-run mode (default), check the result, use the -verbose parameter mode if something look strange. |
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