Date display wrong, homepage timeline is using UTC timezone however the photo time is correct in info page #10417
Comments
|
|
|
Can you try a force refresh/clearing your browser cache? |
Hi, thank you for the response, I tried both incognito and normal model with cache cleared, still the same which is really weird |
|
Just installed Immich and running into the same problem (images are displayed in different 'day folder' than they should be). In my case tho, the displayed dates are weird as well - for instance, one photo shows "Nov 23, 2023 Thu, 7:18 AM GMT-08:00", the photo was taken at 3:18 pm PST, and this is the time that the file modified date displays. Also, some files that are in the wrong 'date folder' are showing in UTC timezone when i view the info. These files appear to be mostly videos, and dont have any exif data. like the other files, the date and time are displayed correctly when viewing the files in a file explorer. |
|
First off, my timezone is PDT, all photos were taken in that timezone, and the server is in that timezone. GPS was disabled on my phone for all the photos and videos that were taken (i only enable it when im needing navigation). First example: Second example: One of the things I tried to make this work better was setting the 'TZ' environment variable to my timezone... but somehow this makes it WORSE in some ways... it seems to have corrected the time display of images in the info pane (tho videos are still incorrect), but those images are now displayed in the wrong date on the timeline when they were correctly displayed before... I also ran into another bug that appears related - when I tried to back up some photos from the android app, they ended up in folders with the incorrect date (in the same way as the timeline shows the incorrect date). |
|
just encountered this as well. 1.107.2 On the android app, the videos appear in EST. which would make you think, if you hit 'right' when viewing vid3, you should go to vid5. I originally hit right arrow 5 times expecing to go to the picture 5 "spaces" to the right, and it didn't. |
|
same issue is still happening now even if I set the TZ in the .env in the latest version today |
Example
MetadataMetadata for a file with yesterday's date{
"id": "0160009b-a8f9-42a9-b56b-9d23ed00be82",
"deviceAssetId": "web-Journal Display Aug 15 2024 (9).jpg-1723763136464",
"ownerId": "ef0c6f2b-87bc-4be0-b236-bb885652168b",
"deviceId": "WEB",
"libraryId": null,
"type": "IMAGE",
"originalPath": "upload/library/admin/2024/2024-08-15/Journal Display Aug 15 2024 (9).jpg",
"originalFileName": "Journal Display Aug 15 2024 (9).jpg",
"originalMimeType": "image/jpeg",
"resized": true,
"thumbhash": "5vcJDQJ/Z12Hd5eVdYVnqa+z5QgL",
"fileCreatedAt": "2024-08-14T23:12:00.000Z",
"fileModifiedAt": "2024-08-15T23:05:36.464Z",
"localDateTime": "2024-08-15T09:12:00.000Z",
"updatedAt": "2024-08-15T23:12:57.372Z",
"isFavorite": false,
"isArchived": false,
"isTrashed": false,
"duration": "0:00:00.00000",
"exifInfo": {
"make": null,
"model": null,
"exifImageWidth": 768,
"exifImageHeight": 1024,
"fileSizeInByte": 99624,
"orientation": null,
"dateTimeOriginal": "2024-08-14T23:12:00.000Z",
"modifyDate": "2024-08-15T23:05:36.464Z",
"timeZone": "UTC+10",
"lensModel": null,
"fNumber": null,
"focalLength": null,
"iso": null,
"exposureTime": null,
"latitude": null,
"longitude": null,
"city": null,
"state": null,
"country": null,
"description": "",
"projectionType": null,
"rating": null
},
"livePhotoVideoId": null,
"people": [],
"checksum": "7Q7PzOJuuzXsDgx3Pc9pQSdiG4k=",
"stackCount": null,
"isOffline": false,
"hasMetadata": true,
"duplicateId": null
}How the file shows up in the UI
Browser localenew Date()
// Fri Aug 16 2024 09:52:47 GMT+1000 (Australian Eastern Standard Time) |
|
I am experiencing this as well. Version infoImmich ExifTool Node.js Libvips ImageMagick FFmpeg Repository Source Build Build Image The below screenshot was taken at August 17, 2024 at 8:33 PM Pacific Time. All of these photos were taken/uploaded on the same day in Pacific Time. 
Browser date: Sat Aug 17 2024 20:33:34 GMT-0700 (Pacific Daylight Time)
Metadata for the first image in "Yesterday"{
"id": "0e6de382-b684-42b1-9411-fda5fa3f8265",
"deviceAssetId": "E5EDE398-69F4-4FAA-94D8-5541E131328A/L0/001",
"ownerId": "c7c204f4-5a70-4074-aed6-6a09ef09f9a6",
"owner": {
"id": "c7c204f4-5a70-4074-aed6-6a09ef09f9a6",
"email": "", // redacted
"name": "TJ Horner",
"profileImagePath": "",
"avatarColor": "green"
},
"deviceId": "85a4bcaa692a512c691f95968385f81e97c9c824305cccfeabe6b740d5e0bdb2",
"libraryId": null,
"type": "IMAGE",
"originalPath": "upload/upload/c7c204f4-5a70-4074-aed6-6a09ef09f9a6/f9/69/f9699162-4000-4abe-8ec5-136038a16725.HEIC",
"originalFileName": "IMG_9848.HEIC",
"originalMimeType": "image/heic",
"resized": true,
"thumbhash": "UQgKDQBFao9oGbhmhoiIqCzPovM8",
"fileCreatedAt": "2024-08-18T03:02:29.732Z",
"fileModifiedAt": "2024-08-18T03:02:29.000Z",
"localDateTime": "2024-08-17T20:02:29.732Z",
"updatedAt": "2024-08-18T03:16:20.266Z",
"isFavorite": false,
"isArchived": false,
"isTrashed": false,
"duration": "0:00:00.000000",
"exifInfo": {
"make": "Apple",
"model": "iPhone 15 Pro",
"exifImageWidth": 4032,
"exifImageHeight": 3024,
"fileSizeInByte": 1337326,
"orientation": "6",
"dateTimeOriginal": "2024-08-18T03:02:29.732Z",
"modifyDate": "2024-08-18T03:02:29.000Z",
"timeZone": "UTC-7",
"lensModel": "iPhone 15 Pro back triple camera 6.765mm f/1.78",
"fNumber": 1.8,
"focalLength": 6.764999866,
"iso": 3200,
"exposureTime": "0.5",
"latitude": 0, // redacted
"longitude": 0, // redacted
"city": "Redmond",
"state": "Washington",
"country": "United States of America",
"description": "",
"projectionType": null,
"rating": null
},
"livePhotoVideoId": null,
"tags": [],
"people": [],
"unassignedFaces": [],
"checksum": "aN1aV91G7ndP+oCYuwA2SPZGVtY=",
"stackCount": null,
"isOffline": false,
"hasMetadata": true,
"duplicateId": null
}Metadata for the photo in "Sun, Aug 18"{
"id": "4a5336c5-614f-4dde-b4b3-835a89e6308f",
"deviceAssetId": "E3998847-BA66-4DBE-8898-9EC93621F863/L0/001",
"ownerId": "c7c204f4-5a70-4074-aed6-6a09ef09f9a6",
"owner": {
"id": "c7c204f4-5a70-4074-aed6-6a09ef09f9a6",
"email": "", // redacted
"name": "TJ Horner",
"profileImagePath": "",
"avatarColor": "green"
},
"deviceId": "85a4bcaa692a512c691f95968385f81e97c9c824305cccfeabe6b740d5e0bdb2",
"libraryId": null,
"type": "IMAGE",
"originalPath": "upload/upload/c7c204f4-5a70-4074-aed6-6a09ef09f9a6/94/35/94354eab-3a1b-455e-b94d-e9a7e3b97a69.jpg",
"originalFileName": "camphoto_1254324197.jpg",
"originalMimeType": "image/jpeg",
"resized": true,
"thumbhash": "CPgFDQCQiE+bqKfXk2h5aIZPbPjF",
"fileCreatedAt": "2024-08-18T03:01:41.000Z",
"fileModifiedAt": "2024-08-18T03:01:41.000Z",
"localDateTime": "2024-08-18T03:01:41.000Z",
"updatedAt": "2024-08-18T03:13:37.510Z",
"isFavorite": false,
"isArchived": false,
"isTrashed": false,
"duration": "0:00:00.000000",
"exifInfo": {
"make": null,
"model": null,
"exifImageWidth": 3024,
"exifImageHeight": 4032,
"fileSizeInByte": 2245290,
"orientation": null,
"dateTimeOriginal": "2024-08-18T03:01:41.000Z",
"modifyDate": "2024-08-18T03:01:41.000Z",
"timeZone": null,
"lensModel": null,
"fNumber": null,
"focalLength": null,
"iso": null,
"exposureTime": null,
"latitude": null,
"longitude": null,
"city": null,
"state": null,
"country": null,
"description": "",
"projectionType": null,
"rating": null
},
"livePhotoVideoId": null,
"tags": [],
"people": [],
"unassignedFaces": [],
"checksum": "1ssXAqBaqKOJLV4wZi9N+X55mgk=",
"stackCount": null,
"isOffline": false,
"hasMetadata": true,
"duplicateId": null
}The correct time and time zone appears for each of the photos when viewing them individually: 
PS: Immich is really great software. Very impressed by the breadth of features and how well it matches competitors like Google Photos. I just purchased an individual license to help keep it alive 😄 |
|
Ok, I did some investigation and it appears to be related to how Here's the problem area: immich/server/src/services/metadata.service.ts Lines 229 to 242 in 5ef9a8f I haven't verified this by stepping through it in a debugger, but here's what I think is happening. This snippet is intended to apply the time zone from the EXIF data to the However, it looks like this step is unnecessary since the // Convert `dateTimeOriginal` to local time zone
luxon.DateTime.fromISO("2024-08-18T03:02:29.732Z").toLocaleString(luxon.DateTime.DATETIME_FULL)
'August 17, 2024 at 8:02 PM PDT'However, since the EXIF data also specifies a time zone of // Convert `localDateTime` to local time zone
luxon.DateTime.fromISO("2024-08-17T20:02:29.732Z").toLocaleString(luxon.DateTime.DATETIME_FULL)
'August 17, 2024 at 1:02 PM PDT'I think the assumption is made that all dates are TZ-less, since the client code for rendering the photos in the timeline specifies UTC as the timezone for immich/web/src/lib/utils/timeline-util.ts Lines 7 to 8 in 5ef9a8f But since the column type in the database is I'll try to get a local dev instance spun up and fix the issue. Hopefully maybe a PR if I am able to! |
|
I can confirm that omitting 
I'll make a PR shortly. |
|
Localdatetime is used to put it into the correct time bin. It is intended to be the local time for where the photo is taken, so the utc conversation is intended. |
|
See #4072 for an explanation |
|
Time zone logic is very messy and is filled with edge cases. Sorry if you already mentioned this, but what camera took the photos, and were they processed in some way? The TZ variable is a bit of a hack where we tell immich the default time zone to apply to photos that lack the information, usually DSLR photos. Modern phone cameras usually have this information correct. The TZ hack fails if you go on a trip to another time zone. The real fix is usually to edit the TZ information of the photos with exiftool. Maybe I should make a guide... It seems like localdatetime stores the wrong date of the photos, in my experience this usually means that the issue is within the metadata of the photos, but I could be wrong. Fun fact, Google photos has terrible support for DSLR photos because they just ignore this issue altogether. If I upload my d700 photos to Google photos and have phone pictures taken of the same event, they will be offset by several hours! Each photo must be manually corrected in the web ui. |
|
The photos are from an iPhone 15 Pro, directly from the Immich mobile app with no processing. This comment includes the full JSON metadata of these photos (at the bottom of the comment) if you want to take a look. The
|
|
That does sound strange. I'm still on vacation for another week or two so I'm only on my phone for now. I think we'll need to add some e2e tests for TZ logic, that infrastructure was not available to us when we made #4072 . Any change to the logic needs extensive testing to make sure all the edge cases are treated correctly. |
I'm curious. Are the photos taken with the iphone with gps on or off? |
|
On. The second one was taken with Telegram's in-app camera, which is why much of the EXIF information is missing. However, the |
|
Ok. As another test, what happens if you unset the TZ variable, rerun metadata extraction for that image and check the info pane? I want to know if it changes. If it does, the photo itself doesn't contain TZ data, it's only assumed from the default time zone set by the TZ variable. |
|
Neither photo changes timestamp in the info pane with TZ unset and metadata extraction re-run. Date, time, and time zone are all correct. |
|
Thanks for verifying |
|
It appears |
|
You mentioned that DSLR photos will often have incorrect EXIF data and will differ by hours from a phone's photo taken at the same time. Do you have examples of those on hand? |
|
(Ignore the below, see next comment for why I am wrong here lol)
|
|
Ok, I'm reading over that original PR again and I think I get the gist of the change. The goal is for assets to be sorted, grouped, etc. by the local time of capture, e.g. if two photos were taken at 00:00 in any time zone, they will still both show up in the same day no matter what. I understand why the times are being formatted as UTC now, since that is intended to be the "local" TZ-less capture date. The issue, then, is happening when the EXIF data has no datetime tags and (Sorry for the thread spam! Just trying to understand the issue and context better.) |
|
Thanks for your help in looking into this. As you can probably tell, this is a can of worms indeed. When I'm back at my computer, I think we should start to add more e2e tests and add relevant TZ cases to our test asset repository. Then we can start changing code. |
Totally. Working with dates is such a pain 😅
Sounds good to me. Let me know if you would like me to send over any of the photos I'm experiencing issues with to assist in writing those test cases. |
|
Was doing some more research on the rendering/formatting part — I know we're waiting for those E2E test cases before doing any implementation work, but thought I'd share some notes here as they may be helpful in the future. Plus, if I try to keep all this ephemeral knowledge about time and time zones in my head I think it may explode. One part of the issue is that the dates are being formatted to the relative time in UTC, since that's how Example: Photo taken on August 18, 2024 at 12:00 in any time zone has const localDateTime = luxon.DateTime.fromISO("2024-08-18T12:00:00.000Z", { zone: "UTC" })
localDateTime.toRelativeCalendar()
> 'yesterday'
// Relative time is correct (this was run in Pacific Time at time of comment)
localDateTime.setZone("default", { keepLocalTime: true }).toRelativeCalendar()
> 'today'
// Local time is preserved (12:00 PM UTC turns into 12:00 PM PDT)
localDateTime.setZone("default", { keepLocalTime: true }).toLocaleString(luxon.DateTime.DATETIME_FULL)
> 'August 18, 2024 at 12:00 PM PDT'Hopefully this makes sense. It's difficult to illustrate/explain 😅 |
|
I'll have a look at this. Personal note: issue surfaces in album c539fe5-5ae3-4275-b27a-48eba9050341. |
|
Some insights (only web, I haven't looked at the app). I'm in Germany and my browser is configured to use Europe/Berlin, which currently is at offset +2. The Immich server container is also using Europe/Berlin.
|
|
There are a lot of similar time issue topics. I'm trying to follow them as i have this issue or similar like others. Here i posted some screenshots showing the date of the DB container not using the environmental variable. Could that be an issue, and possible why the photos show as yesterday (like i'm running a few hours in the future)? I show time i took screenshots, and showing "yesterday" but it was still today. Conainer was running a few hours ahead not using eastern or new york time zone. I didn't want to repost all my screenshots, so i'll link to this other thread. |
|
There are multiple threads with this issue. In one of the threads I'm following, which I mentioned at previous post, It looks like someone might have posted a fix. Link below. I'm on my mobile so I'm having difficulty formatting things correctly if someone wants to tidy up my post feel free. |
|
I'd like to close this in favor of #12650. Any objections? |
|
Oh and actually, it may have been fixed by the PR @sirweazel referenced, yea. Could someone verify? |
|
If the fix mentioned above has been put into the latest release, then its not fixed yet. The issue still exists in 1.116, in fact if anything its gotten WORSE, now the times/dates in the info panel are incorrect as well. to illustrate - my server still has the TZ environment variable set to "America/Los_Angeles" |
|
Did you re-extract metadata for those again? |
|
i selected them and did 'refresh metadata' from the hamburger menu. i havnt done a full db refresh tho |
|
That should be enough. I'd like to close this in favor of #12650 though, as that's supposed to bundle all those issues. I'd appreciate it if you could post a message summarizing the issue there, and also provide a sample file (as a zip archive). |
|
Most of the images from today show "Yesterday" and one shows in the future "Sun, Sep 29". |
The bug
Hello, just upgraded to the latest v1.106.4, I just uploaded a photo which was taken on GMT-4 on June 16 however on the homepage this picture is displaying under tomorrow's date which is Jun 17, in the photo info page it is correct
The OS that Immich Server is running on
ubuntu 22.04
Version of Immich Server
1.106.4
Version of Immich Mobile App
1.106.4
Platform with the issue
Your docker-compose.yml content
Your .env content
Reproduction steps
Relevant log output
No response
Additional information
No response
The text was updated successfully, but these errors were encountered: