starred/immich

Fork 0

mirror of https://github.com/immich-app/immich.git synced 2026-03-02 22:57:45 -05:00

Date group title in web timeline confuses time zones #4750

New issue

Open

opened 2026-02-20 03:09:58 -05:00 by deekerman · 6 comments

deekerman commented

2026-02-20 03:09:58 -05:00

Owner

Originally created by @C-Otto on GitHub (Jan 24, 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 24, 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"

deekerman added the

🖥️web

date-time

labels

2026-02-20 03:09:58 -05:00

deekerman commented

2026-02-20 03:09:58 -05:00

Author

Owner

@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.

deekerman commented

2026-02-20 03:09:59 -05:00

Author

Owner

@shark2k commented on GitHub (Feb 27, 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 27, 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

deekerman commented

2026-02-20 03:09:59 -05:00

Author

Owner

@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...

deekerman commented

2026-02-20 03:09:59 -05:00

Author

Owner

@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.

deekerman commented

2026-02-20 03:09:59 -05:00

Author

Owner

@semiligneous commented on GitHub (Apr 7, 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 7, 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

deekerman commented

2026-02-20 03:09:59 -05:00

Author

Owner

@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.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/immich#4750

No description provided.

Rows
Columns