Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changing date from web UI doesn't respect timezone's DST #11887

Open
2 of 3 tasks
MMauro94 opened this issue Aug 18, 2024 · 2 comments
Open
2 of 3 tasks

Changing date from web UI doesn't respect timezone's DST #11887

MMauro94 opened this issue Aug 18, 2024 · 2 comments
Labels

Comments

@MMauro94
Copy link
Contributor

The bug

When selecting a a timezone in the date/time change dialog, you can also select a IANA timezone identifier, such as Europe/Rome. These timezones support changes in offset (for example, due to Daylight Savings Time).

However, it seems that timezones in this dialog are fixed at a predetermined offset (the one for the current date?), while they should take the correct offset based on the selected date/time.

The OS that Immich Server is running on

Debian 12

Version of Immich Server

v1.112.1

Version of Immich Mobile App

v1.112.1

Platform with the issue

  • Server
  • Web
  • Mobile

Your docker-compose.yml content

version: "3.8"

services:
  immich-server:
    container_name: immich-server
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    volumes:
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
      - /etc/localtime:/etc/localtime:ro
    env_file:
      - .env
    depends_on:
      - redis
      - database
    restart: always

  immich-machine-learning:
    container_name: immich-machine-learning
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
    volumes:
      - model-cache:/cache
    env_file:
      - .env
    restart: always


  redis:
    container_name: immich-redis
    image: redis:6.2-alpine
    restart: always


  database:
    container_name: immich-postgres
    image: tensorchord/pgvecto-rs:pg14-v0.2.0
    env_file:
      - .env
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_DB: ${DB_DATABASE_NAME}
    volumes:
      - pgdata:/var/lib/postgresql/data
    restart: always


volumes:
  pgdata:
    name: immich-db
  model-cache:
    name: immich-model-cache

networks:
  default:
    external:
      name: web_services

Your .env content

DB_HOSTNAME=immich-postgres
DB_USERNAME=<REDACTED>
DB_PASSWORD=<REDACTED>
DB_DATABASE_NAME=immich
REDIS_HOSTNAME=immich-redis
UPLOAD_LOCATION=<REDACTED>/immich
TYPESENSE_API_KEY=<REDACTED>
PUBLIC_LOGIN_PAGE_MESSAGE=

LOG_LEVEL=log

IMMICH_VERSION=v1.112.1

Reproduction steps

1. Open any photo in the Immich web UI
2. Open the change date/time dialog
3. Select the date `2023-11-01 00:00`
4. Select the timezone `Europe/Rome`
5. Make the changes
6. Observe that the set timezone is `UTC+2` rather than `UTC+1` (`Europe/Rome` changes from DST to standard time on `2023-10-29`)

Example with java.time APIs: https://pl.kotl.in/kXXpe6Yzq
If you run the above code snippet, you'll see that the computed offset changes based on the local date/time it is being computed on.

Relevant log output

N/A

Additional information

Looking at the API request that is made, I see that the request is:

{"dateTimeOriginal":"2023-11-01T00:00:00.000+02:00"}

So I presume the timezone -> offset computation is done on the client side. Maybe the API should accept a local date time and a timezone ID and the computation should be done by the server?

Ideally, the server would store the timezone ID and compute only when needed, but I'm not sure if the XMP format supports it. The databse definitely supports timezone ID in the timeZone column in the exif table, as I see this kind of data present in my instance:

SELECT DISTINCT "timeZone"
FROM "exif"
ORDER BY "timeZone"
America/New_York
Australia/Sydney
Etc/GMT
Europe/Belgrade
Europe/Berlin
Europe/Budapest
Europe/Dublin
Europe/Helsinki
Europe/London
Europe/Madrid
Europe/Paris
Europe/Prague
Europe/Rome
Europe/Vienna
Europe/Warsaw
Europe/Zurich
UTC
UTC+1
UTC+2
@sondercoder
Copy link

I am also experiencing this issue.

@rothardo
Copy link

rothardo commented Oct 2, 2024

is this issue up for grab? @alextran1502 please let me know as I would like to work on the same

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants