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

Date group title in web timeline confuses time zones #5220

New Issue
Open
opened 2026-02-05 11:15:22 +03:00 by OVERLORD · 6 comments
OVERLORD commented 2026-02-05 11:15:22 +03:00
Owner
Copy Link

Originally created by @C-Otto on GitHub (Jan 25, 2025).

The bug

See https://github.com/immich-app/immich/discussions/12650#discussioncomment-11949425 and https://github.com/immich-app/immich/discussions/12650#discussioncomment-11926346

The date shown for the group may be "today" or "yesterday". This is determined based on the comparison of "now" and the asset's date, truncated to midnight (start of the day). During this, the asset date's local time is used (which is UTC from a technical point of view), whereas the browser time (now) might include time zone offset information. As a result of this, an asset created today, having the "localDateTime" of today, might be shown as "yesterday" or "tomorrow".

web/src/lib/utils/timeline-util.ts:98

Version of Immich Server

v1.125.2

Platform with the issue

  • Server
  • Web
  • Mobile

Reproduction steps

  • modify asset time to today's date, 00:00:00 in time zone Pacific/Honolulu
  • set server's time zone to Pacific/Honolulu (TZ in .env)
  • set browser system's time zone to Pacific/Honolulu timedatectl set-timezone Pacific/Honolulu
  • set local time to 13:59:00 date -s "2025-xx-yy 13:59:00"
  • see image show as "today"
  • wait until time is 14:00 (which is midnight UTC)
  • see image show as "yesterday"
Originally created by @C-Otto on GitHub (Jan 25, 2025). ### The bug See https://github.com/immich-app/immich/discussions/12650#discussioncomment-11949425 and https://github.com/immich-app/immich/discussions/12650#discussioncomment-11926346 The date shown for the group may be "today" or "yesterday". This is determined based on the comparison of "now" and the asset's date, truncated to midnight (start of the day). During this, the asset date's local time is used (which is UTC from a technical point of view), whereas the browser time (now) might include time zone offset information. As a result of this, an asset created today, having the "localDateTime" of today, might be shown as "yesterday" or "tomorrow". `web/src/lib/utils/timeline-util.ts:98` ### Version of Immich Server v1.125.2 ### Platform with the issue - [ ] Server - [x] Web - [ ] Mobile ### Reproduction steps - modify asset time to today's date, 00:00:00 in time zone Pacific/Honolulu - set server's time zone to Pacific/Honolulu (TZ in .env) - set browser system's time zone to Pacific/Honolulu `timedatectl set-timezone Pacific/Honolulu` - set local time to 13:59:00 `date -s "2025-xx-yy 13:59:00"` - see image show as "today" - wait until time is 14:00 (which is midnight UTC) - see image show as "yesterday"
OVERLORD added the 🖥️webdate-time labels 2026-02-05 11:15:22 +03:00
OVERLORD commented 2026-02-05 11:15:25 +03:00
Author
Owner
Copy Link

@antoniosarro commented on GitHub (Jan 29, 2025):

Hello, I've investigated a bit and it seems like the problem is with the luxon library that's being used in this function web/src/lib/utils/timeline-util.ts:98-116. The line .toLocaleString(groupDateFormat, { locale }) doesn't take into account the system's locale settings.

I created some functions with the built-in Date to replace those that use luxon, and it seems like at least for my timezone (Europe/Rome) the problem is fixed. However, I'd like to check the library again to see if there are any known issues or changes that might be causing the problem.

I believe that, however, given that in the end the functions used in this library are always the same, they could be defined internally within the project ad-hoc, so as to have one less dependency that could break again.

I'll update as soon as I have news.

@antoniosarro commented on GitHub (Jan 29, 2025): Hello, I've investigated a bit and it seems like the problem is with the `luxon` library that's being used in this function `web/src/lib/utils/timeline-util.ts:98-116`. The line `.toLocaleString(groupDateFormat, { locale })` doesn't take into account the system's locale settings. I created some functions with the built-in `Date` to replace those that use `luxon`, and it seems like at least for my timezone (Europe/Rome) the problem is fixed. However, I'd like to check the library again to see if there are any known issues or changes that might be causing the problem. I believe that, however, given that in the end the functions used in this library are always the same, they could be defined internally within the project ad-hoc, so as to have one less dependency that could break again. I'll update as soon as I have news.
OVERLORD commented 2026-02-05 11:15:26 +03:00
Author
Owner
Copy Link

@shark2k commented on GitHub (Feb 28, 2025):

Hello, I've investigated a bit and it seems like the problem is with the luxon library that's being used in this function web/src/lib/utils/timeline-util.ts:98-116. The line .toLocaleString(groupDateFormat, { locale }) doesn't take into account the system's locale settings.

I created some functions with the built-in Date to replace those that use luxon, and it seems like at least for my timezone (Europe/Rome) the problem is fixed. However, I'd like to check the library again to see if there are any known issues or changes that might be causing the problem.

I believe that, however, given that in the end the functions used in this library are always the same, they could be defined internally within the project ad-hoc, so as to have one less dependency that could break again.

I'll update as soon as I have news.

So I noticed you had worked on a fix for this only to be informed that this is apparently working as expected by @jrasm91.

Re-reading through it again, it appears that there is more than one datetime field.
There is the exif.dateTimeOriginal which jrasm91 says has the time zone aware date and the localDateTime field.

It appears the web app at least is using the localDateTime in order to determine the various time references, when it appears it should be using the exif.dateTimeOriginal so that it is in the local time zone (and combined with exif.timeZone in order to be able to account for viewing the page in a different time zone and having the proper time references shown).

I do understand the logic behind why they are doing what they are doing with the localDateTime field, but I feel like the field should be labeled something different like forcedUtcDateTime or adjustedUtcDateTime (I feel like there is a word that would describe this but I just cannot remember it). If this field is only used for the timeline to keep similar events grouped (like New Years Eve in the jrasm91's example), it could even be timelineAdjustedUtcDateTime so that it is known what it is actually being used for.

As it is with the current behavior, it is not how most/all people would expect this to behave. If someone took at picture at 1600 EST, for example, at 2200 EST that same day, they would not expect the picture to be referred to as having been taken "yesterday" when they know they took the picture that day.

Thank you for looking into the issue and revealing the root cause behind this.
I am hoping that the team will be willing to make the change so that the behavior of the time references will be accurate in the web app. As I am not familiar with the code, I am not sure how much work would be involved, but just based on what info was given in your discussion in your linked fix, it almost seems like it might be as "simple" as the code that handles the time references being updated to use the exif.dateTimeOriginal and exif.timeZone fields to determine the datetime that needs to be used to determine the time references.

-Shark2k

@shark2k commented on GitHub (Feb 28, 2025): > Hello, I've investigated a bit and it seems like the problem is with the `luxon` library that's being used in this function `web/src/lib/utils/timeline-util.ts:98-116`. The line `.toLocaleString(groupDateFormat, { locale })` doesn't take into account the system's locale settings. > > I created some functions with the built-in `Date` to replace those that use `luxon`, and it seems like at least for my timezone (Europe/Rome) the problem is fixed. However, I'd like to check the library again to see if there are any known issues or changes that might be causing the problem. > > I believe that, however, given that in the end the functions used in this library are always the same, they could be defined internally within the project ad-hoc, so as to have one less dependency that could break again. > > I'll update as soon as I have news. So I noticed you had worked on a fix for this only to be informed that this is apparently working as expected by @jrasm91. Re-reading through it again, it appears that there is more than one datetime field. There is the `exif.dateTimeOriginal` which jrasm91 says has the time zone aware date and the `localDateTime` field. It appears the web app at least is using the `localDateTime` in order to determine the various time references, when it appears it should be using the `exif.dateTimeOriginal` so that it is in the local time zone (and combined with `exif.timeZone` in order to be able to account for viewing the page in a different time zone and having the proper time references shown). I do understand the logic behind why they are doing what they are doing with the `localDateTime` field, but I feel like the field should be labeled something different like `forcedUtcDateTime` or `adjustedUtcDateTime` (I feel like there is a word that would describe this but I just cannot remember it). If this field is only used for the timeline to keep similar events grouped (like New Years Eve in the jrasm91's example), it could even be `timelineAdjustedUtcDateTime` so that it is known what it is actually being used for. As it is with the current behavior, it is not how most/all people would expect this to behave. If someone took at picture at 1600 EST, for example, at 2200 EST that same day, they would not expect the picture to be referred to as having been taken "yesterday" when they know they took the picture that day. Thank you for looking into the issue and revealing the root cause behind this. I am hoping that the team will be willing to make the change so that the behavior of the time references will be accurate in the web app. As I am not familiar with the code, I am not sure how much work would be involved, but just based on what info was given in your discussion in your linked fix, it almost seems like it might be as "simple" as the code that handles the time references being updated to use the `exif.dateTimeOriginal` and `exif.timeZone` fields to determine the datetime that needs to be used to determine the time references. -Shark2k
OVERLORD commented 2026-02-05 11:15:27 +03:00
Author
Owner
Copy Link

@skyoptic commented on GitHub (Mar 20, 2025):

This is not fixed in 1.129.0 - photos taken now at 9:30pm Pacific Time upload to the server as expected and show as Yesterday. Version installed from git using Arch Linux AUR script, no docker...

@skyoptic commented on GitHub (Mar 20, 2025): This is not fixed in 1.129.0 - photos taken now at 9:30pm Pacific Time upload to the server as expected and show as Yesterday. Version installed from git using Arch Linux AUR script, no docker...
OVERLORD commented 2026-02-05 11:15:28 +03:00
Author
Owner
Copy Link

@C-Otto commented on GitHub (Mar 23, 2025):

This is not fixed in 1.129.0

An easy way to check the state of this is to have a look at the top left in GitHub. If it says "Open", it's not fixed yet.

@C-Otto commented on GitHub (Mar 23, 2025): > This is not fixed in 1.129.0 An easy way to check the state of this is to have a look at the top left in GitHub. If it says "Open", it's not fixed yet.
OVERLORD commented 2026-02-05 11:15:29 +03:00
Author
Owner
Copy Link

@semiligneous commented on GitHub (Apr 8, 2025):

@C-Otto - is there an expected date where this will be fixed? I assume there is no debate that this is a problem, but perhaps some discussion about the best way to fix it?

being based in Australia (UTC +10), I often see assets labelled under "Tomorrow" in my timeline (if I take an image in the morning and then look at it in Immich), as well as always having many are incorrectly labelled as "today". That timeline view, grouping by day, makes things harder to navigate instead of easier, so would be lovely to see it addressed! Thanks

@semiligneous commented on GitHub (Apr 8, 2025): @C-Otto - is there an expected date where this will be fixed? I assume there is no debate that this is a problem, but perhaps some discussion about the best way to fix it? being based in Australia (UTC +10), I often see assets labelled under "Tomorrow" in my timeline (if I take an image in the morning and then look at it in Immich), as well as always having many are incorrectly labelled as "today". That timeline view, grouping by day, makes things harder to navigate instead of easier, so would be lovely to see it addressed! Thanks
OVERLORD commented 2026-02-05 11:15:30 +03:00
Author
Owner
Copy Link

@C-Otto commented on GitHub (Apr 8, 2025):

No. It just needs to be done, I think my reproduction steps should help a lot. I don't feel comfortable messing with frontend code, though, so we need to wait for someone to pick this up.

@C-Otto commented on GitHub (Apr 8, 2025): No. It just needs to be done, I think my reproduction steps should help a lot. I don't feel comfortable messing with frontend code, though, so we need to wait for someone to pick this up.
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 date-time 🖥️web
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#5220
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?