immich-app/immich
1
0
Fork 0
mirror of https://github.com/immich-app/immich.git synced 2026-07-25 14:00:45 +03:00
Code Issues 783 Packages Projects Releases 22 Wiki Activity

Frontend does not convert fileCreatedAt to local time for assets lacking EXIF metadata #7663

New Issue
Closed
opened 2026-02-05 13:12:28 +03:00 by OVERLORD · 2 comments
OVERLORD commented 2026-02-05 13:12:28 +03:00
Owner
Copy Link

Originally created by @SkyLordJay on GitHub (Oct 30, 2025).

I have searched the existing issues, both open and closed, to make sure this is not a duplicate report.

  • Yes

The bug

What's happening?
The Immich webview and sometimes IOS app fail to apply the correct local time to assets lacking EXIF metadata (such as a photo downloaded from Instagram)

Web view
The web view consistently shows the timestamp without any UTC offset, being 4 hours ahead of the local time America/New_York in my case.

Immich IOS App
Shows the correct local time if the original photo is still present on the device.
If the original photo is delete from the device, eventually the app will show the incorrect timestamp with no UTC offset. It's a bit inconsistent because I think it only happens after a cache of the original is cleared.

Information
I've set the 'TZ' environmental variable to America/New_York

I checked the asset database for my photo and the fileCreatedAt value reads 2025-10-27 20:45:56+00 so it is stripped of the time zone, which should probably be expected since I'd assume the frontend ends should apply the localizations, but they're not.

I noticed that the API for the asset/get (getAssetInfo) endpoint has this to say about fileCreatedAt

"The actual UTC timestamp when the file was created/captured, preserving time zone information... Combined with time zone data, this can be used to determine the exact moment the photo was taken."

But when I requested the asset info myself using http://localhost:2283/api/assets/8c224d1d-913f-41fc-9619-3b6627074629?apiKey=<key> the fileCreatedAt field read this 2025-10-27T20:45:56.000Z which does not preserve the time zone despite what the API docs say, and since this asset doesn't have EXIF metadata, there's no way to figure out which time locale it was taken at. This wouldn't necessarily be an issue assuming the web view formats it according to the browsers locale as stated in the settings

"Format dates and numbers based on your browser locale"

But that does not appear to be happening for these assets that lack EXIF metadata

I believe this is the same issue that's mentioned in this discussion: discussioncomment-14722077 and discussioncomment-14722387 But I couldn't find any open or closed issues on it, just a bunch of old debates about which time value should be used.

The OS that Immich Server is running on

Debian GNU/Linux 12 (bookworm)

Version of Immich Server

v2.2.0 build.18950480972

Version of Immich Mobile App

2.1.0 build.231

Platform with the issue

  • Server
  • Web
  • Mobile

Device make and model

iPhone 11, Chromium Browsers (Brave, Google Chrome, Edge)

Your docker-compose.yml content

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}:/usr/src/app/upload
      - /etc/localtime:/etc/localtime:ro
      - /mnt/d/Immich_test:/mnt/photos_test:ro
    env_file:
      - .env
    ports:
      - '2283:2283'
    depends_on:
      - redis
      - database
    restart: always
    healthcheck:
      disable: false

  immich-machine-learning:
    container_name: immich_machine_learning
    # For hardware acceleration, add one of -[armnn, cuda, rocm, openvino, rknn] to the image tag.
    # Example tag: ${IMMICH_VERSION:-release}-cuda
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
    # extends: # uncomment this section for hardware acceleration - see https://immich.app/docs/features/ml-hardware-acceleration
    #   file: hwaccel.ml.yml
    #   service: cpu # set to one of [armnn, cuda, rocm, openvino, openvino-wsl, rknn] for accelerated inference - use the `-wsl` version for WSL2 where applicable
    volumes:
      - model-cache:/cache
    env_file:
      - .env
    restart: always
    healthcheck:
      disable: false

  redis:
    container_name: immich_redis
    image: docker.io/valkey/valkey:8-bookworm@sha256:fec42f399876eb6faf9e008570597741c87ff7662a54185593e74b09ce83d177
    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
    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
    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=./library

# The location where your database files are stored. Network shares are not supported for the database
DB_DATA_LOCATION=./postgres

# 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=America/New_York

# 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=postgres

# The values below this line do not need to be changed
###################################################################################
DB_USERNAME=postgres
DB_DATABASE_NAME=immich

Reproduction steps

  1. Obtain a photo lacking EXIF metadata on your mobile device (like an Image from Instagram or Discord)
  2. Back it up to your Immich server using the IOS app
  3. Use the web view to check the timestamp it was taken at.

For me it's always four hours in the future since no UTC time zone offset is being applied.
Despite the correct TZ environmental variable and browser time locale settings as mentioned in the bug explanation above.

Relevant log output

Additional information

The details I mentioned in the bug explanation above could also indicate issues with the documentation of fileCreatedAt for the API (getAssetInfo) endpoint. But perhaps I'm misunderstanding the wording.

Originally created by @SkyLordJay on GitHub (Oct 30, 2025). ### I have searched the existing issues, both open and closed, to make sure this is not a duplicate report. - [x] Yes ### The bug **What's happening?** The Immich webview and sometimes IOS app fail to apply the correct local time to assets lacking EXIF metadata (such as a photo downloaded from Instagram) **Web view** The web view consistently shows the timestamp without any UTC offset, being 4 hours ahead of the local time `America/New_York` in my case. **Immich IOS App** Shows the correct local time if the original photo is still present on the device. If the original photo is delete from the device, eventually the app will show the incorrect timestamp with no UTC offset. It's a bit inconsistent because I think it only happens after a cache of the original is cleared. **Information** I've set the 'TZ' environmental variable to `America/New_York` I checked the asset database for my photo and the `fileCreatedAt` value reads `2025-10-27 20:45:56+00` so it is stripped of the time zone, which should probably be expected since I'd assume the frontend ends should apply the localizations, but they're not. I noticed that the API for the asset/get ([getAssetInfo](https://api.immich.app/endpoints/assets/getAssetInfo)) endpoint has this to say about `fileCreatedAt` > "The actual UTC timestamp when the file was created/captured, preserving time zone information... Combined with time zone data, this can be used to determine the exact moment the photo was taken." But when I requested the asset info myself using `http://localhost:2283/api/assets/8c224d1d-913f-41fc-9619-3b6627074629?apiKey=<key>` the `fileCreatedAt` field read this `2025-10-27T20:45:56.000Z` which does not preserve the time zone despite what the API docs say, and since this asset doesn't have EXIF metadata, there's no way to figure out which time locale it was taken at. This wouldn't necessarily be an issue assuming the web view formats it according to the browsers locale as stated in the settings > "Format dates and numbers based on your browser locale" But that does not appear to be happening for these assets that lack EXIF metadata I believe this is the same issue that's mentioned in this discussion: [discussioncomment-14722077](https://github.com/immich-app/immich/discussions/12650#discussioncomment-14722077) and [discussioncomment-14722387](https://github.com/immich-app/immich/discussions/12650#discussioncomment-14722387) But I couldn't find any open or closed issues on it, just a bunch of old debates about which time value should be used. ### The OS that Immich Server is running on Debian GNU/Linux 12 (bookworm) ### Version of Immich Server v2.2.0 build.18950480972 ### Version of Immich Mobile App 2.1.0 build.231 ### Platform with the issue - [ ] Server - [x] Web - [x] Mobile ### Device make and model iPhone 11, Chromium Browsers (Brave, Google Chrome, Edge) ### Your docker-compose.yml content ```YAML 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}:/usr/src/app/upload - /etc/localtime:/etc/localtime:ro - /mnt/d/Immich_test:/mnt/photos_test:ro env_file: - .env ports: - '2283:2283' depends_on: - redis - database restart: always healthcheck: disable: false immich-machine-learning: container_name: immich_machine_learning # For hardware acceleration, add one of -[armnn, cuda, rocm, openvino, rknn] to the image tag. # Example tag: ${IMMICH_VERSION:-release}-cuda image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release} # extends: # uncomment this section for hardware acceleration - see https://immich.app/docs/features/ml-hardware-acceleration # file: hwaccel.ml.yml # service: cpu # set to one of [armnn, cuda, rocm, openvino, openvino-wsl, rknn] for accelerated inference - use the `-wsl` version for WSL2 where applicable volumes: - model-cache:/cache env_file: - .env restart: always healthcheck: disable: false redis: container_name: immich_redis image: docker.io/valkey/valkey:8-bookworm@sha256:fec42f399876eb6faf9e008570597741c87ff7662a54185593e74b09ce83d177 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 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 restart: always volumes: model-cache: ``` ### Your .env content ```Shell # 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=./library # The location where your database files are stored. Network shares are not supported for the database DB_DATA_LOCATION=./postgres # 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=America/New_York # 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=postgres # The values below this line do not need to be changed ################################################################################### DB_USERNAME=postgres DB_DATABASE_NAME=immich ``` ### Reproduction steps 1. Obtain a photo lacking EXIF metadata on your mobile device (like an Image from Instagram or Discord) 2. Back it up to your Immich server using the IOS app 3. Use the web view to check the timestamp it was taken at. For me it's always four hours in the future since no UTC time zone offset is being applied. Despite the correct TZ environmental variable and browser time locale settings as mentioned in the bug explanation above. ### Relevant log output ```shell ``` ### Additional information The details I mentioned in the bug explanation above could also indicate issues with the documentation of `fileCreatedAt` for the API ([getAssetInfo](https://api.immich.app/endpoints/assets/getAssetInfo)) endpoint. But perhaps I'm misunderstanding the wording.
OVERLORD commented 2026-02-05 13:12:29 +03:00
Author
Owner
Copy Link

@bo0tzz commented on GitHub (Oct 30, 2025):

Please start by posting in #12650

@bo0tzz commented on GitHub (Oct 30, 2025): Please start by posting in #12650
OVERLORD commented 2026-02-05 13:12:31 +03:00
Author
Owner
Copy Link

@SkyLordJay commented on GitHub (Oct 30, 2025):

I already posted in #12650 and I even quoted two others that are experiencing the same issue, I thought since there hasn't been much of an address to it and it was different from what the other people in that thread was sharing that it made sense to open an issue. Forgive me if that was wrong.

@SkyLordJay commented on GitHub (Oct 30, 2025): I already posted in #12650 and I even quoted two others that are experiencing the same issue, I thought since there hasn't been much of an address to it and it was different from what the other people in that thread was sharing that it made sense to open an issue. Forgive me if that was wrong.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
accessibility
changelog:enhancement
changelog:security
changelog:skip
changelog:translation
cli
date-time
dependencies
documentation
external-library
format
good first issue
mobile-beta
mobile-beta
mobile-beta
needs-answer
nice to have
pull-request
Mirrored from GitHub Pull Request
 sharing
tech-debt
📱mobile
🖥️web
🗄️server
🧠machine-learning
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#7663
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?