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

Web timeline shows photos as one day in the future but matadata has todays date. #2066

New Issue
Closed
opened 2026-02-05 04:56:19 +03:00 by OVERLORD · 17 comments
OVERLORD commented 2026-02-05 04:56:19 +03:00
Owner
Copy Link

Originally created by @natedawg on GitHub (Jan 27, 2024).

The bug

Near the end of the day I saved a photo from the internet and uploaded it to immich. However the web timeline is listing the photo as one day in the future. There are photos saved an d uploaded from earlier today that are under the correct time heading Today

The android app shows the correct date heading in the timeline.

Example:
Incorrect timeline date: Sat, Jan 27
Photo details date: Jan 26, 2024 Fri, 9:08 PM
Current local time: Jan 26, 2024 10:30PM

The OS that Immich Server is running on

Docker

Version of Immich Server

v1.93.3

Version of Immich Mobile App

v1.93.3

Platform with the issue

  • Server
  • Web
  • Mobile

Your docker-compose.yml content

immich_server and immich_microservices is mounting the volume 
`- /etc/localtime:/etc/localtime:ro`

Your .env content

NA

Reproduction steps

1. During the last few hours of the day upload a photo that was just taken/saved.

Additional information

No response

Originally created by @natedawg on GitHub (Jan 27, 2024). ### The bug Near the end of the day I saved a photo from the internet and uploaded it to immich. However the web timeline is listing the photo as one day in the future. There are photos saved an d uploaded from earlier today that are under the correct time heading `Today` The android app shows the correct date heading in the timeline. Example: Incorrect timeline date: `Sat, Jan 27` Photo details date: `Jan 26, 2024 Fri, 9:08 PM` Current local time: `Jan 26, 2024 10:30PM` ### The OS that Immich Server is running on Docker ### Version of Immich Server v1.93.3 ### Version of Immich Mobile App v1.93.3 ### Platform with the issue - [ ] Server - [X] Web - [ ] Mobile ### Your docker-compose.yml content ```YAML immich_server and immich_microservices is mounting the volume `- /etc/localtime:/etc/localtime:ro` ``` ### Your .env content ```Shell NA ``` ### Reproduction steps ```bash 1. During the last few hours of the day upload a photo that was just taken/saved. ``` ### Additional information _No response_
OVERLORD commented 2026-02-05 04:56:30 +03:00
Author
Owner
Copy Link

@mmomjian commented on GitHub (Jan 30, 2024):

I don't believe Immich uses /etc/localtime - per https://immich.app/docs/install/environment-variables you need to set the env var TZ for the immich-microservices container. Is this set?

What time exactly is shown on the picture in question through the web interface?

@mmomjian commented on GitHub (Jan 30, 2024): I don't believe Immich uses /etc/localtime - per https://immich.app/docs/install/environment-variables you need to set the env var TZ for the immich-microservices container. Is this set? What time exactly is shown on the picture in question through the web interface?
OVERLORD commented 2026-02-05 04:56:37 +03:00
Author
Owner
Copy Link

@natedawg commented on GitHub (Jan 30, 2024):

I do not have TZ set and the docker-compose.yml provided in the repo has the - /etc/localtime:/etc/localtime:ro as a mount point. However I don't think it matters since the details page shows the correct date and the android app timeline is correct. It's just the web timeline logic that is bugged.

The photo details on the web shows the correct time Jan 26, 2024 Fri, 9:08 PM but the timeline displays the photo as being from the next day Sat, Jan 27.

@natedawg commented on GitHub (Jan 30, 2024): I do not have `TZ` set and the docker-compose.yml provided in the repo has the `- /etc/localtime:/etc/localtime:ro` as a mount point. However I don't think it matters since the details page shows the correct date and the android app timeline is correct. It's just the web timeline logic that is bugged. The photo details on the web shows the correct time `Jan 26, 2024 Fri, 9:08 PM` but the timeline displays the photo as being from the next day `Sat, Jan 27`.
OVERLORD commented 2026-02-05 04:56:42 +03:00
Author
Owner
Copy Link

@mmomjian commented on GitHub (Jan 30, 2024):

Oh, that is strange. I think the docs may need some updating then because they reference to setting TZ for immich-microservices. Additionally, in my experience I had a number of files that didn't have the timezone correctly set until I specified TZ in addition to the localtime mountpoint.

@mmomjian commented on GitHub (Jan 30, 2024): Oh, that is strange. I think the docs may need some updating then because they reference to setting TZ for `immich-microservices`. Additionally, in my experience I had a number of files that didn't have the timezone correctly set until I specified `TZ` in addition to the localtime mountpoint.
OVERLORD commented 2026-02-05 04:56:45 +03:00
Author
Owner
Copy Link

@natedawg commented on GitHub (Feb 8, 2024):

UPDATE: I just noticed the opposite is also happening. Images are being displayed under the Today heading when they where taken/modified yesterday. Again the mobile app shows them correctly.

@natedawg commented on GitHub (Feb 8, 2024): UPDATE: I just noticed the opposite is also happening. Images are being displayed under the `Today` heading when they where taken/modified yesterday. Again the mobile app shows them correctly.
OVERLORD commented 2026-02-05 04:56:49 +03:00
Author
Owner
Copy Link

@figadore commented on GitHub (Mar 19, 2024):

I'm having the same problem, but it only appears to affect videos for me. It looks fine on the mobile app, but the web app groups them into the wrong day (based on the UTC time of the video). The timezone listed in the info view for the photos correctly displays -7, but for the videos is listed as UTC or GMT+0 on both web and mobile

@figadore commented on GitHub (Mar 19, 2024): I'm having the same problem, but it only appears to affect videos for me. It looks fine on the mobile app, but the web app groups them into the wrong day (based on the UTC time of the video). The timezone listed in the info view for the photos correctly displays -7, but for the videos is listed as UTC or GMT+0 on both web and mobile
OVERLORD commented 2026-02-05 04:56:57 +03:00
Author
Owner
Copy Link

@igor47 commented on GitHub (May 2, 2024):

same issue here. example photo with metadata view:
image
but in the timeline, the same photo appears on tuesday:
image

this maybe has to do with UTC? it seems right around the UTC day boundary that photos shift into the next day.

@igor47 commented on GitHub (May 2, 2024): same issue here. example photo with metadata view: ![image](https://github.com/immich-app/immich/assets/200575/d1c789c2-7ba0-455a-ae05-0dbccca8dafc) but in the timeline, the same photo appears on tuesday: ![image](https://github.com/immich-app/immich/assets/200575/a62e8b09-c585-439b-9882-b8d1ec3f5794) this maybe has to do with UTC? it seems right around the UTC day boundary that photos shift into the next day.
OVERLORD commented 2026-02-05 04:57:04 +03:00
Author
Owner
Copy Link

@aedelbro commented on GitHub (May 3, 2024):

This issue thread seems to be the closest to what I'm seeing as well.
The android app is working as expected (today is Friday, and all photos show under thursday when they were taken):
phone

However in web, some photos show under thursday, and some show under today (friday). And probably a separate issue, but it goes from Tuesday -> Today (friday) -> thursday:
Screenshot 2024-05-03 at 10 23 58 AM

All the photos were taken on Thursday, and the metadata for all of them is proper. The split appears to be around the UTC day split (as others pointed out).

Screenshot 2024-05-03 at 10 28 24 AM
Screenshot 2024-05-03 at 10 28 35 AM

Everything is latest for me, v1.103.1 for server, and 1.103.1 build.137 for android.

@aedelbro commented on GitHub (May 3, 2024): This issue thread seems to be the closest to what I'm seeing as well. The android app is working as expected (today is Friday, and all photos show under thursday when they were taken): ![phone](https://github.com/immich-app/immich/assets/36162221/2363f775-26d8-4a0c-bca3-c2740d235044) However in web, some photos show under thursday, and some show under today (friday). And probably a separate issue, but it goes from Tuesday -> Today (friday) -> thursday: ![Screenshot 2024-05-03 at 10 23 58 AM](https://github.com/immich-app/immich/assets/36162221/36fbe5c4-af4b-40d5-bdd9-6655de644b15) All the photos were taken on Thursday, and the metadata for all of them is proper. The split appears to be around the UTC day split (as others pointed out). ![Screenshot 2024-05-03 at 10 28 24 AM](https://github.com/immich-app/immich/assets/36162221/1da65f69-57e0-429b-8b00-1ffcff18aaf6) ![Screenshot 2024-05-03 at 10 28 35 AM](https://github.com/immich-app/immich/assets/36162221/c264da4d-a109-4500-b081-f4dd2d1e4e6a) Everything is latest for me, `v1.103.1` for server, and `1.103.1 build.137` for android.
OVERLORD commented 2026-02-05 04:57:10 +03:00
Author
Owner
Copy Link

@danieldietzler commented on GitHub (Sep 6, 2024):

Hey, if this is still an issue could you provide a sample image (as a zip file)?

@danieldietzler commented on GitHub (Sep 6, 2024): Hey, if this is still an issue could you provide a sample image (as a zip file)?
OVERLORD commented 2026-02-05 04:57:19 +03:00
Author
Owner
Copy Link

@aedelbro commented on GitHub (Sep 6, 2024):

@danieldietzler I'm away from computer atm, but can confirm it's still an issue with latest web (both issues I mentioned above: some photos appearing in wrong days, and days showing on the timeline out of order) . I'll upload test photos and config env vars when I'm able tonight or tomorrow.

@aedelbro commented on GitHub (Sep 6, 2024): @danieldietzler I'm away from computer atm, but can confirm it's still an issue with latest web (both issues I mentioned above: some photos appearing in wrong days, and days showing on the timeline out of order) . I'll upload test photos and config env vars when I'm able tonight or tomorrow.
OVERLORD commented 2026-02-05 04:57:24 +03:00
Author
Owner
Copy Link

@jrasm91 commented on GitHub (Sep 6, 2024):

Perfect, thanks! Make sure you re-run metadata extraction on those photos and that they are still wrong after that.

@jrasm91 commented on GitHub (Sep 6, 2024): Perfect, thanks! Make sure you re-run metadata extraction on those photos and that they are still wrong after that.
OVERLORD commented 2026-02-05 04:57:29 +03:00
Author
Owner
Copy Link

@aedelbro commented on GitHub (Sep 6, 2024):

@danieldietzler @jrasm91 Still happening on the latest 114.0 release. I re-ran the metadata extraction (both in the admin panel, and "refresh metadata" on each photo).
Here's 2 test images. Both photos were taken on Thursday May 2nd, and like I mentioned above, the drink photo was taken later (suspiciously after GMT midnight).

The only relevant variable / setting changed from default is TZ=America/Indiana/Indianapolis.

And the container has the appropriate local time:

root@d623dffe94dc:/# date
Fri Sep  6 01:18:43 PM EDT 2024
@aedelbro commented on GitHub (Sep 6, 2024): @danieldietzler @jrasm91 Still happening on the latest 114.0 release. I re-ran the metadata extraction (both in the admin panel, and "refresh metadata" on each photo). [Here's 2 test images](https://github.com/user-attachments/files/16911102/TZ.Test-20240906_125118.2.zip). Both photos were taken on Thursday May 2nd, and like I mentioned above, the drink photo was taken later (suspiciously after GMT midnight). The only relevant variable / setting changed from default is `TZ=America/Indiana/Indianapolis`. And the container has the appropriate local time: ``` root@d623dffe94dc:/# date Fri Sep 6 01:18:43 PM EDT 2024 ```
OVERLORD commented 2026-02-05 04:57:38 +03:00
Author
Owner
Copy Link

@danieldietzler commented on GitHub (Sep 6, 2024):

Hey @aedelbro, the snapchat image seems to have completely stripped metadata. There isn't anything on there really. Could you provide the original file?

@danieldietzler commented on GitHub (Sep 6, 2024): Hey @aedelbro, the snapchat image seems to have completely stripped metadata. There isn't anything on there really. Could you provide the original file?
OVERLORD commented 2026-02-05 04:57:45 +03:00
Author
Owner
Copy Link

@aedelbro commented on GitHub (Sep 7, 2024):

@danieldietzler I noticed that as well. That's the file directly downloaded from Immich; I can get the original original from my phone if needed (but I think that's a red herring). As far as I can tell, there is no metadata associated to those images outside of the timestamp (classic snapchat). Other photos have the same issue that aren't snapchat, standard images from my camera app (with more metadata). The snapchat one of a drink was easiest to show since it didn't have faces everywhere to be redacted.

Further investigation that I'm doing that might be of assistance:

  • Not sure why it got this way, but this group of photos have slightly different timezones associated
    • Of the 8 photos on the timeline as May 2nd, 7 had a -4.30 offset, and 1 (the much earlier album photo) has -4 offset
    • Of the 4 photos on the timeline as May 3rd (again all shot on the 2nd local), all 4 have -4 offset
    • All 12 photos taken on that day were in the same timezone, so all should be -4
  • When clicking into a photo, the left and right navigations appear to be correct
    • Starting on the album photo (the earliest from the 2nd), and clicking "left" to go into the relative future, it correctly goes through the images in order (like 95% sure).

This leads me to think it's specifically the timeline view incorrectly grouping by day, and not a metadata on any individual photo.

Let me know if there's other info I can provide. I'll try taking some basic pictures tonight and see if I can easily replicate it (I know I've seen it happen on other 8pm eastern / 9pm eastern splits depending on daylight savings)

@aedelbro commented on GitHub (Sep 7, 2024): @danieldietzler I noticed that as well. That's the file directly downloaded from Immich; I can get the original original from my phone if needed (but I think that's a red herring). As far as I can tell, there is no metadata associated to those images outside of the timestamp (classic snapchat). Other photos have the same issue that aren't snapchat, standard images from my camera app (with more metadata). The snapchat one of a drink was easiest to show since it didn't have faces everywhere to be redacted. Further investigation that I'm doing that might be of assistance: * Not sure why it got this way, but this group of photos have slightly different timezones associated * Of the 8 photos on the timeline as May 2nd, 7 had a -4.30 offset, and 1 (the much earlier album photo) has -4 offset * Of the 4 photos on the timeline as May 3rd (again all shot on the 2nd local), all 4 have -4 offset * All 12 photos taken on that day were in the same timezone, so all _should_ be -4 * When clicking into a photo, the left and right navigations appear to be correct * Starting on the album photo (the earliest from the 2nd), and clicking "left" to go into the relative future, it correctly goes through the images in order (like 95% sure). This leads me to think it's specifically the timeline view incorrectly grouping by day, and not a metadata on any individual photo. Let me know if there's other info I can provide. I'll try taking some basic pictures tonight and see if I can easily replicate it (I know I've seen it happen on other 8pm eastern / 9pm eastern splits depending on daylight savings)
OVERLORD commented 2026-02-05 04:57:50 +03:00
Author
Owner
Copy Link

@aedelbro commented on GitHub (Sep 7, 2024):

So the saved snapchat ones might be classified differently. My guess is there's a different sorting mechanism for "calculated timezone" vs "timezone exif data". And the calculated / default TZ photos get sorted on the timeline using GMT/UTC, and everything that has full timezone exif data gets calculated differently.

I started taking photos of a notepad, and recorded time on the pad in addition to order. Note this screenshot is after 8pm (GMT midnight here), so it says "yesterday". Potentially related, potentially not.
Screenshot 2024-09-06 200619

I then made sure to get some saved snapchat photos in there as well.

What I'm seeing is it tries to display the "first photo" (lets assume we're at top of timeline). How it calculates "most recent photo for first" seems to be accurate regardless of photo (snap or standard). However it groups the photos (this is potentially the bad logic), it groups them together. It then shows "the next group", which is the most recent photo from that grouping.

so in my situation, if I have a snapchat photo most recent, it'll show all of that day's group (calculated incorrectly for the snapchat photos), then the past day (even though some of those photos are more recent than other photos in the more recent group).

Here are the ordering and type of photos from my experiment (if I don't specify snapchat, it's my camera app with location data):
1 @ 6.31 -> 2 @ 7.10 -> 3 @ 7.47 -> 4 @ 8.05 -> 3d print spool @ 8.08 (snap) -> 5 @ 8.20 -> 6 @ 8.27 -> 6 @ 8.28 (snap) -> 7 @ 8.33

And depending if it's camera or snap as the most recent photo, depends on which "day" shows up first.
Examples:
Here is upto 5 @ 8.20 (note the spool in the "back" even though it's 2nd most recent)
Screenshot 2024-09-06 202108

Here is upto 6 @ 8.28 (snap) (note the spool teleports up with the most recent)
Screenshot 2024-09-06 202909

Here is upto 7 @ 8.33 (note how the most recent camera pulls all the correctly calculated days to the "front", pushing some of the more recent snap photos to the "back")
Screenshot 2024-09-06 203452

It'll take a bit for me to remove the location data from all the photos, but I'll upload the lot of those here in a bit.

@aedelbro commented on GitHub (Sep 7, 2024): So the saved snapchat ones might be classified differently. My guess is there's a different sorting mechanism for "calculated timezone" vs "timezone exif data". And the calculated / default TZ photos get sorted on the timeline using GMT/UTC, and everything that has full timezone exif data gets calculated differently. I started taking photos of a notepad, and recorded time on the pad in addition to order. Note this screenshot is after 8pm (GMT midnight here), so it says "yesterday". Potentially related, potentially not. ![Screenshot 2024-09-06 200619](https://github.com/user-attachments/assets/56ad39de-31aa-4841-b48a-15ca99e534ee) I then made sure to get some saved snapchat photos in there as well. What I'm seeing is it tries to display the "first photo" (lets assume we're at top of timeline). How it calculates "most recent photo for first" seems to be accurate regardless of photo (snap or standard). However it groups the photos (this is potentially the bad logic), it groups them together. It then shows "the next group", which is the most recent photo from that grouping. so in my situation, if I have a snapchat photo most recent, it'll show all of that day's group (calculated incorrectly for the snapchat photos), then the past day (even though some of those photos are more recent than other photos in the more recent group). Here are the ordering and type of photos from my experiment (if I don't specify snapchat, it's my camera app with location data): 1 @ 6.31 -> 2 @ 7.10 -> 3 @ 7.47 -> 4 @ 8.05 -> 3d print spool @ 8.08 (snap) -> 5 @ 8.20 -> 6 @ 8.27 -> 6 @ 8.28 (snap) -> 7 @ 8.33 And depending if it's camera or snap as the most recent photo, depends on which "day" shows up first. Examples: Here is upto 5 @ 8.20 (note the spool in the "back" even though it's 2nd most recent) ![Screenshot 2024-09-06 202108](https://github.com/user-attachments/assets/c2fd1a2c-4e33-4af5-b6d3-04e18ae3a6db) Here is upto 6 @ 8.28 (snap) (note the spool teleports up with the most recent) ![Screenshot 2024-09-06 202909](https://github.com/user-attachments/assets/8c64de03-4e4c-4c05-867f-0427476c3e01) Here is upto 7 @ 8.33 (note how the most recent camera pulls all the correctly calculated days to the "front", pushing some of the more recent snap photos to the "back") ![Screenshot 2024-09-06 203452](https://github.com/user-attachments/assets/a3208630-e7ac-422d-9d15-98d4c3835853) It'll take a bit for me to remove the location data from all the photos, but I'll upload the lot of those here in a bit.
OVERLORD commented 2026-02-05 04:57:59 +03:00
Author
Owner
Copy Link

@aedelbro commented on GitHub (Sep 7, 2024):

Here's the zipped files downloaded from Immich (sans location data, and a few photos since GH only allows 25MB uploads).

I've also confirmed that the individual photo left/right navigation works 100% as I would expect (amongst this test sample set)

Hopefully all the above is enough reproduction steps / investigation data. Lemmie know if there's more I can provide 😎

@aedelbro commented on GitHub (Sep 7, 2024): [Here's](https://github.com/user-attachments/files/16913941/immich.photos.zip) the zipped files downloaded from Immich (sans location data, and a few photos since GH only allows 25MB uploads). I've also confirmed that the individual photo left/right navigation works 100% as I would expect (amongst this test sample set) Hopefully all the above is enough reproduction steps / investigation data. Lemmie know if there's more I can provide 😎
OVERLORD commented 2026-02-05 04:58:03 +03:00
Author
Owner
Copy Link

@C-Otto commented on GitHub (Sep 7, 2024):

Duplicate of #10417

@C-Otto commented on GitHub (Sep 7, 2024): Duplicate of #10417
OVERLORD commented 2026-02-05 04:58:06 +03:00
Author
Owner
Copy Link

@danieldietzler commented on GitHub (Sep 7, 2024):

Thank you very much @aedelbro for doing such thorough investigation and providing all the details! This will definitely help :)

@danieldietzler commented on GitHub (Sep 7, 2024): Thank you very much @aedelbro for doing such thorough investigation and providing all the details! This will definitely help :)
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#2066
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?