[PR #12150] [CLOSED] fix(web,server): time zone related fixes #13504

Closed
opened 2026-02-05 15:15:54 +03:00 by OVERLORD · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/immich-app/immich/pull/12150
Author: @C-Otto
Created: 8/30/2024
Status: Closed

Base: mainHead: timezones


📝 Commits (5)

  • 3f684db fix several time zone related issues in the "change date" dialog
  • c622a59 work around exiftool-vendored bug: retain +00:00 timezone if set explicitly
  • c4821ac fix
  • 8b4ed80 fix
  • f5a8b98 fix

📊 Changes

2 files changed (+113 additions, -32 deletions)

View changed files

📝 server/src/services/metadata.service.ts (+23 -4)
📝 web/src/lib/components/shared-components/change-date.svelte (+90 -28)

📄 Description

This is a draft. I'd be happy to receive feedback! Related to #10417.

  • If a date ends with "+00:00" and exiftool-vendored does not return any time zone information, assume "UTC+00:00" instead (relevant for Iceland and lots of African countries).
  • When changing a date in the web UI, only show time zones that are valid for the configured date. As an example, currently the code shows "Europe/Berlin (+02:00)" which is wrong for photos taken in winter and might cause "off by one hour" issues. This is now automatically updated to "Europe/Berlin (+01:00)" when changing the date from summer to winter (or initially opening the dialog for such a date). Furthermore, certain times just don't exist in certain time zones, for example "Mar 31 2024 02:30:00" for "Europe/Berlin" (due to time skipping from 2am to 3am, daylight saving time).
  • Time zone information is not forwarded to the frontend code (yet). As such, we have to show a time zone that matches the given offset. If the offset matches the offset of the time zone configured in the user's browser (at the date and time, see winter/summer issue above), the time zone is selected automatically. For German users this means "Europe/Berlin" is shown instead of "Africa/Blantyre" if just "+02:00" is known.
  • The local time was used in places where it shouldn't be used. We now set the time zone right from the start instead of messing up the date object with information inferred from the locale time zone (causing issues for dates that are invalid in said zone).
  • The configured time zone is transported to the job creating/updating the XMP sidecar file, which previously didn't work for "+00:00" offsets.

Future work:

  • Provide already known timezone to details list and dropdown component so that it can be shown (I have some pictures with very detailled information, which is just thrown away - only the offset is used!)
  • Persist time zone explicitly (in the corresponding exif database column) if set explicitly via the UI. Currently, we throw away the time zone (Europe/Berlin) and just continue with the offset (+02:00).

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/immich-app/immich/pull/12150 **Author:** [@C-Otto](https://github.com/C-Otto) **Created:** 8/30/2024 **Status:** ❌ Closed **Base:** `main` ← **Head:** `timezones` --- ### 📝 Commits (5) - [`3f684db`](https://github.com/immich-app/immich/commit/3f684db5bff1f9eb88caaf70a5e34f810b6a3efd) fix several time zone related issues in the "change date" dialog - [`c622a59`](https://github.com/immich-app/immich/commit/c622a59deb0008eeefbcfba7cb153a60b27c6e23) work around exiftool-vendored bug: retain +00:00 timezone if set explicitly - [`c4821ac`](https://github.com/immich-app/immich/commit/c4821acd620633635390bf003f795a638aad017e) fix - [`8b4ed80`](https://github.com/immich-app/immich/commit/8b4ed80e53a1ee68acbc8acb0fd12ef0c726464d) fix - [`f5a8b98`](https://github.com/immich-app/immich/commit/f5a8b98ae143d56a5d70bd9ce33b0dc3e7c860ec) fix ### 📊 Changes **2 files changed** (+113 additions, -32 deletions) <details> <summary>View changed files</summary> 📝 `server/src/services/metadata.service.ts` (+23 -4) 📝 `web/src/lib/components/shared-components/change-date.svelte` (+90 -28) </details> ### 📄 Description This is a draft. I'd be happy to receive feedback! Related to #10417. - If a date ends with "+00:00" and exiftool-vendored does not return any time zone information, assume "UTC+00:00" instead (relevant for Iceland and lots of African countries). - When changing a date in the web UI, only show time zones that are valid for the configured date. As an example, currently the code shows "Europe/Berlin (+02:00)" which is wrong for photos taken in winter and might cause "off by one hour" issues. This is now automatically updated to "Europe/Berlin (+01:00)" when changing the date from summer to winter (or initially opening the dialog for such a date). Furthermore, certain times just don't exist in certain time zones, for example "Mar 31 2024 02:30:00" for "Europe/Berlin" (due to time skipping from 2am to 3am, daylight saving time). - Time zone information is not forwarded to the frontend code (yet). As such, we have to show _a_ time zone that matches the given offset. If the offset matches the offset of the time zone configured in the user's browser (at the date and time, see winter/summer issue above), the time zone is selected automatically. For German users this means "Europe/Berlin" is shown instead of "Africa/Blantyre" if just "+02:00" is known. - The local time was used in places where it shouldn't be used. We now set the time zone right from the start instead of messing up the date object with information inferred from the locale time zone (causing issues for dates that are invalid in said zone). - The configured time zone is transported to the job creating/updating the XMP sidecar file, which previously didn't work for "+00:00" offsets. Future work: - Provide already known timezone to details list and dropdown component so that it can be shown (I have some pictures with very detailled information, which is just thrown away - only the offset is used!) - Persist time zone explicitly (in the corresponding exif database column) if set explicitly via the UI. Currently, we throw away the time zone (Europe/Berlin) and just continue with the offset (+02:00). --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
OVERLORD added the pull-request label 2026-02-05 15:15:54 +03:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#13504