Replies: 131 comments 274 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.
-
|
When I upload photos to Immich after changing their date and time using the default iOS Photos app, they are uploaded with the original capture date instead of the adjusted one. I have attached a zip file containing a photo taken on January 9th, which I adjusted to January 8th on iOS before uploading it to Immich. This issue occurs not only with photos taken with the iOS camera app but also with screenshots and images downloaded from other applications (i.e., files that originally do not contain EXIF data). It appears that date and time adjustments made within the iOS Photos app are not being reflected in Immich.
|
Beta Was this translation helpful? Give feedback.
-
|
So I might have an answer to some people: I was using a Canon DSLR, and all the pictures uploaded to immich were changed to a timezone of +09:00. |
Beta Was this translation helpful? Give feedback.
-
|
I'm concerned about discrepancies in date display between the web and iOS apps. In the photo list view, Photo A displays as follows: The date information for Photo A is as follows: My iPhone's time zone is Asia/Tokyo +9:00. It appears the iOS app is displaying the date with a 9-hour addition. |
Beta Was this translation helpful? Give feedback.
-
|
Immich is not extracting metadata and video thumbnails from DJI Osmo Action 6 |
Beta Was this translation helpful? Give feedback.
-
|
Hi team, I get the following behavior : I have pictures coming from different time zones taken at roughly the same time. I would expect them to be next to each other in the timeline, but they are categorized into two distinct days. It's annoying for my use-case, but I'm not even sure that immirch is doing anything wrong here (other than not allowing to disable grouping photos by day in the interface) 
|
Beta Was this translation helpful? Give feedback.
-
|
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.
-
|
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.
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