Time (zone) difference from web upload

[GeoffreyFrogeye]

I tried to take this breathtaking picture of my wall at exactly 15:55:55, in Europe/Amsterdam time which both my phone (with which I took the picture) and my computer (with which I use immich-go on) are set to.

When uploaded to via the Immich app or web app, the web app does show that the picture was taken at 15:55 GMT+2:00. When uploaded via immich-go, the web app shows that the picture was taken at 17:55 GMT+2:00, which is incorrect. This is the case whether I set -time-zone=Europe/Amsterdam or not. I did delete and empty the trash to make sure the duplicate detection wasn't causing issues.

Looking at the GET /api/assets/:id endpoint for both upload ways, it seems that with immich-go some date fields use a time of 15:55:54.000Z which seems to match the filename; while with the web interface those are using the UTC time (13:...) and have millisecond precision, which seems to match the EXIF data:

[asset id and other expected diffs above from a re-upload skipped]
-  "deviceId": "WEB",
+  "deviceId": "curacao",
   "libraryId": null,
   "type": "IMAGE",
   "originalPath": "/srv/media/pictures/library/geoffrey/2024/08/2024-08-20-15-55-54-982.jpg",
@@ -17,10 +17,10 @@
   "originalMimeType": "image/jpeg",
   "resized": true,
   "thumbhash": "KQgCBQBQZ493R3iIiIaIeHOPJ/eG",
-  "fileCreatedAt": "2024-08-20T13:55:55.561Z",
-  "fileModifiedAt": "2024-08-20T13:57:28.347Z",
-  "localDateTime": "2024-08-20T15:55:55.561Z",
-  "updatedAt": "2024-08-20T14:02:48.780Z",
+  "fileCreatedAt": "2024-08-20T15:55:54.000Z",
+  "fileModifiedAt": "2024-08-20T15:55:54.000Z",
+  "localDateTime": "2024-08-20T15:55:54.000Z",
+  "updatedAt": "2024-08-20T14:01:54.333Z",
   "isFavorite": false,
   "isArchived": false,
   "isTrashed": false,
@@ -32,7 +32,7 @@
     "exifImageHeight": 3000,
     "fileSizeInByte": 1485144,
     "orientation": "6",
-    "dateTimeOriginal": "2024-08-20T13:55:55.561Z",
+    "dateTimeOriginal": "2024-08-20T15:55:54.000Z",
     "modifyDate": "2024-08-20T13:55:55.593Z",
     "timeZone": "Europe/Brussels",
     "lensModel": null,

Notice that the exifInfo.modifyDate is the same in both.
I have no idea why it says Europe/Brussels, though in practice it should be the same as Europe/Amsterdam?

I am aware that there is a -when-no-date option that generates the date from the filename when it cannot be determined (I assume from the EXIF data). So my questions are as follow:

• Why is it using the filename as date? Is this a bug or an usage issue?
• As I have uploaded many pictures with immich-go in the past, would there be a bulk way to identify the ones that have a wrong date and fix them, either from the web interface or from the API?

Some additional info:

• Immich v1.111.0, installed using this nixpkgs commit
• immich-go v0.21.1, installed using this nixpkgs commit

[simulot]

at exactly 15:55:55,
You are as nerd as I am :-)

Let's say this is a feature. This allow an immediate guess of the capture date without the need to read the file.
This trick works perfectly with my own phone (a pixel 6), that set the file name with the UTC timestamp... until an user is reporting their phone is using local time... in China...

You are right... This is not mandatory.

I propose the the following:

• not use this feature by default
• add a flag to control the feature, and precise the TZ to use: UTC/Local or any TZ

[GeoffreyFrogeye]

Yeah, and I figured some other cases where this might be an issue: your past self named pictures like "Event YYYY-MM-DD NNN" with NNN being an incrementing counter which will be interpreted as hour/minute, or when you had to save pictures from your trash which adds another timestamp to the file, or ran into synchronisation conflicts. It would somehow prevent changing the date from the UI, because immich-go would write to a different Exif tag in the .xmp file.

I agree that not using this feature by default might be a good idea. Ideally Immich would be the one to have this feature so it would be able to only do so if Exif data is missing, and this would simplify immich-go, but for now I think this feature does have its place in here. I was happy to have pictures from a friend's phone (also a Pixel) that did not have Exif data still have (2h shifted) time data.

As for fixing pictures that might have wrong time, I started writing some elaborate script finding the .xmp pictures that had only tags that immich-go would set, but I realized I had not so much actual data saved in those, so I just deleted them all and ran the sidecar syncing job in Immich.