[MEGATHREAD] Date/time/timezone issues

[jrasm91]

As everyone should know by now, photo and video metadata is a bit of a mess. On top of that, we're also now talking about timezones. Long story short, we know there will always be room for improvement in this area.

If you have an issue with:

• Photo or video showing up in the wrong place in the timeline
• Photo or video with the wrong date day, time, or timezone
• Photos or videos taken at the same time not showing up next to each other

Please post a comment in this discussion with the following, and we will happily investigate the issue.

• a zip of your file
• the expected date, including timezone
• current date produced by immich

EDIT: if you don't post the three points mentioned above, you're comment will simply be marked as off topic and hidden.

[mmomjian]

Can we also ask people to include their .env with the TZ variable and the output of date both on the host and in the immich_server container?

[jrasm91]

Even without it I will be able to tell if it will fallback to a default timezone or not, so it doesn't really matter IMO.

[ygaeon]

Adding my old issue #9331 to here ... (no need to duplicate info, right?)

1. Not a zip-file but a link to the uploaded asset in the linked issue IMG_20240504_164142.jpg
2. 2024-05-04 16:41:42 +0200 (CET)
3. 05/04/2024, 06:41 PM (18:41) Africa/Blantyre (+02:00)

[jrasm91]

You post is quite large actually. Can you post exactly:

1. Zip file with bad asset
2. Expected day, time, + timezone
3. Current day, time, + timezone shown in immich

[ygaeon]

Updated my comment..

[jrasm91]

So this photo has no time zone information in at it all. From the exif we get:

{
  "SubSecDateTimeOriginal": "2024:06:05 00:20:20.979349",
  "DateTimeOriginal": "2024:06:05 00:20:20",
  "CreateDate": "2024:06:05 00:20:20"
}

I would expect it to:

• Show under the June 5th header in the timeline
• Display as 12:20am on June 5th in the detail panel and without a timezone

It looks like the second point isn't happening because it is displaying it using the viewer's timezone. I'll make a PR to change that.

[jrasm91]

The second point should be addressed with #12779

[ygaeon]

#9331 was just closed by @danieldietzler .
There's a lot of work going into that issue by us reporting it so please don't forget that information in that issue.

[malkavi]

Hi, I also have a lot of photos misplaced in my timeline. Those photos are old photos from external libraries.
I think the problem may be related to the lack of some metadata field (date:create and date:modify). And when importing immich modifies the files by creating those fields (??).
Maybe is my fault, I moved some folders to a new structure and lost the file creating date... Not sure. Move date can be the fake date.

Some photos from Google Takeout does not have any useful metadata.

IMG_20130913_081540.JPG:
Real date: 13/09/2013
Fake: 08/07/2024

PANO_20170416_105856.jpg:
Real date 16/April/2017
Fake date 08/July/2024

Metadata:
date:create: 2024-07-08T18:55:36+00:00
date:modify: 2024-07-08T18:55:36+00:00
exif:DateTime: 2017:04:16 10:58:56
exif:ExifOffset: 82
exif:GPSDateStamp: 2017:04:16

CameraZOOM-20150715115510237.jpg:
Real: 15/072015
Fake: 08/07/2024
Metadata:
date:create: 2024-07-08T18:54:40+00:00
date:modify: 2024-07-08T18:54:40+00:00
exif:DateTime: 2015:07:15 11:55:35

IMG_20151222_135145.vr.jpg:
Real: 22/122015
Fake: 08/07/2024
date:create: 2024-07-08T18:54:37+00:00
date:modify: 2024-07-08T18:54:37+00:00
exif:ColorSpace: 1
exif:DateTime: 2015:12:22 13:52:19
immich_malkavi_20240917.zip

[radh21301]

Hey. I think this thread is about things showing up in the wrong place when the images have metadata.

Yours is borked up because of google and has no metadata. I would try to fix that first. Some options:

• Use immich-go for takeout files. it is the one recommended by this community
• OR fix the metadata/date yourself - looks like all the names of the images have the date and time attached to it. So, you can use exiftool fort this..something like this:
  exiftool "-alldates<filename" -P ./
  Please research into exiftool before you do anything.

[chris-butterworth]

Immich v1.111.0

Hey, I am having issues with the location data.

I made the switch to immich by exporting 20k photos from Apple Photos to a directory, then imported them into Immich at a later date.

The issus is that some photos, mainly ones taking in the USA in my case, are showing up in China or the middle of the ocean.

I have found that the longitude is being calculated incorrectly, it is positive in Immich, when it should be a negative value. Flipping longitude to negative fixes location.

Original Coordinates:
Latitude: 32° 46' 59.13" N
Longitude: 96° 47' 3.6" W

Immich's Coordinates after import
Latitude: 32.78310
Longitude: 96.78433

I did search for the issue but couldn't find anyone else reporting it

[radh21301]

Hey. This thread is about timezone/timeline issues - but I suppose incorrect GPS can affect where the images shows in a timeline.
There is this post in the 'Discussions' tab, which you might not have noticed if you searched in the 'Issues'. #12224
The suggestion there was to rerun metadata extraction for this image and check of it looks okay. I uploaded your image to my server, and it shows up in Dallas, Texas - which seems to be correct. So, it does seem like whatever bug was there previously was fixed.

[D-dragon197]

Sony dslr-a550

a zip of your file: DSC09740.ZIP
the expected date, including timezone: 16 mrt 2024, 12:39 GMT+01:00
current date produced by immich: 16 mrt 2024, za 13:39 GMT+01:00

[jrasm91]

The file has a date time, but no timezone. On the latest release it shows up on the web at 12:39 and without a timezone.

"DateTimeOriginal": "2024:03:16 12:39:31",

[igor47]

i have this problem as well, shooting photos with my GRIIIx. i think the reason is that i keep any sort of GPS tagging turned off, and the photos coming out of the camera do not have time zone info. my photos make it into immich via an external library.

i would like to keep both the camera and the server in UTC and then have the photos display in the correct timezone for the users browser.

[radh21301]

Hey. Did you upgrade to the latest update? I think there is a fix for what you observe. You might not have to mess with the timezones in the server and the camera.

[igor47]

ah right you are! i attempted to refresh metadata, and it didn't seem to be working but it just took a minute -- the files are now showing up on the correct date. i will run a library-wide re-scan. thanks!

[snuq]

as requested, posting my experience over here as well.
currrently running immich 1.116

Immich displays a lot of my images and videos in the wrong date in the timeline, and in the incorrect timezone. for example:

all those photos were taken on the 10th, which immich seems to at least have an idea of internally or it wouldnt be putting them BELOW the other photos.... in previous versions, the info panel for the lower photos would say the correct date of the 10th, but now the info panel shows the 11th:

(info for the first image on the 11th)

this also happens with most videos:

(all were taken on the 29th)
and the info for the third video in the 30th folder:

My server is running in PST timezone, photos were taken in PST timezone, browser is in the PST timezone, and i have the TZ variable set in my environment variables on the server:
TZ=America/Los_Angeles

Attaching both a zip of the video:
P1299136.zip

and the image:
IMG_20230610_194503.zip

[snuq]

Upgraded to Immich 1.118.0.
Files with timezone data have improved, they are actually showing in the correct locations in the timeline.
Unfortunately, files without any exif data but correct modified and created dates are still displayed incorrectly.
both images:

and videos:

note that the file time and date for the same file are simultaneously displayed correctly in the windows explorer window on the left, but not in the immich info pane

Additionally, there is still the sorting bug in the immich timeline with these files

(ie, the videos that immich thinks are newer from the 30th should be sorted above the images from the 29th)

[C-Otto]

Did you rescan the metadata for those files?

[snuq]

I ran extract metadata on all twice

[snuq]

to provide an update: the incorrect positioning for videos without metadata (but correct file attributes) is still present in current immich (v1.120.2).
also, to clarify, there appear to be two bugs here:

1. videos without metadata but with correct modified/created dates are timestamped incorrectly (i do not know if the timzone is set in the file data and being read wrong, or if it does not have timezone data and immich is not using the local timezone as it should, but the files are listed correctly when browsing them in windows and in linux)
2. the web interface of immich is displaying the above files in the wrong order (newer files should be above older ones, but these are displayed below)

Without knowing the specifics of immich's code, i cant guess if they are the same bug or maybe just a related bug, just specifying both to be safe.

[technopaw]

I would like to add on to snuq as well. Same issue here with images that have no metadata date or time zone showing the wrong time. With these images it converts it from the correct MST to UTC. On the iPhone and Android Mobile app everything is showing correctly it is just in the web app. I have tried 3 different browsers Edge, Chrome, and safari and in incognito and not in incognito. I have also tried the mobile version of these browsers all showing the same converted date. I am on Immich version 1.121.0

[jrasm91]

If you want me to look at anything you need to do the following:

• add a zip of your file
• list the expected date, including timezone
• list current date produced by immich

[basicfu]

me too.....
1.116.0 date error
Photos without a time zone should use the set time zone, I don't understand why they are updated in reverse

[basicfu]

@C-Otto Hello, here's my question

[C-Otto]

This image does not contain any timezone information.

[basicfu]

Yes, many of my pictures do not include time zones. In previous versions, the offset was set by default, but now that the update is complete, the offset time will no longer be applied
Can a setting option be implemented to freely choose whether exif is offset from the time zone?
Or do I have any way to solve it?

[C-Otto]

@jrasm91 maybe you can chime in?

[jrasm91]

Applying an arbitrary offset is quite confusing and misleading a lot of the time. We've chosen to just show it in "local time" if there is no timezone information available. After #13262 is released this will display 1:55AM on Jan 1st, 2024 in the asset detail panel.

[bo0tzz]

This is just bad metadata, you should fix the file.

[HackerJL]

Moved a lot of photos out of Apple Photos, and kept the EXIF data intact, but a bunch of them showing up with the wrong date, but you can see the metadata right in immich, so not sure why it shows up like this.

Expected date is listed, just not sure where the first date is coming from or why immich cares about it?

[C-Otto]

The assets use the timezone offset "-05:59" in the tags that usually are used to determine the creation date. This offset is treated as an invalid offset, which is why the rest of the information is also left unused. Do you know why -05:59 is used instead of -06:00?

"SubSecCreateDate": "2017:04:02 10:26:27.763-05:59"

[HackerJL]

Oh my. That is odd. I have no clue why thats the case. Just iPhone (2 different ones). So if thats fixed up Immich is happy?

[C-Otto]

I'm pretty sure, yeah.

[HackerJL]

Worked 100%. Thank you!

[raimundmeyer]

a zip of your file

20240907_161623.zip

the expected date, including timezone

2024-09-07 16:16 (as in the filename) Timezone on the server and the browser as well as immich $TZ Europe/Berlin +02:00

current date produced by immich

date is correct, but the two hours offset of the timezone are falsely deducted

[C-Otto]

If you manually edited the metadata, you may need to delete the XMP file and refresh again. Other than that it should work (refresh metadata with v1.117.0).

[basicfu]

hello, I am currently using v1.117.0,Refreshing does not show any changes. If manually deleting. xmp and refreshing again, the following error message will appear, and the time is still incorrect

7e6c5bfee23a [Nest] 2  - 10/08/2024, 11:15:09 AM    WARN [Microservices:Error: File not found - /usr/src/app/upload/library/admin/2024/IMG_2332.PNG.xmp
7e6c5bfee23a     at ReadTask._ExifToolTask_parser (/usr/src/app/node_modules/exiftool-vendored/dist/ExifToolTask.js:76:71)
7e6c5bfee23a     at ReadTask.parser (/usr/src/app/node_modules/exiftool-vendored/dist/ExifToolTask.js:47:167)
7e6c5bfee23a     at ReadTask._Task_resolve (/usr/src/app/node_modules/batch-cluster/dist/Task.js:146:40)] Error reading exif data (upload/library/admin/2024/IMG_2332.PNG.xmp): Error: File not found - /usr/src/app/upload/library/admin/2024/IMG_2332.PNG.xmp
7e6c5bfee23a [Nest] 2  - 10/08/2024, 11:15:09 AM    WARN [Microservices:MetadataService] Asset 0895a2ba-8e90-4211-9d22-b92ad20f123d has no time zone information

[basicfu]

@C-Otto Can a setting option be implemented to freely choose whether exif is offset from the time zone?

[C-Otto]

@basicfu you are responding in @raimundmeyer's thread. My response is to him and about the photos provided in the first comment. Please open a new thread in here if you have another issue (and provide an example photo to us).

[raimundmeyer]

Refreshed metadata and looks good now. Thanks @C-Otto

[igor47]

ok, i'm now having more bizarre behavior. here's a zip with photos 1975 and 1990 served from my server since the file size exceeds github's allowed file limit: https://igor.moomers.org/random/immich-debug-photos.zip

1975 metadata:

1990 metadata:

the end result in my timeline is that 1975 is totally correct. it appears under sat sept 28 in the timeline, and what's more, it correctly appears after other photos taken with my cell phone that saturday in the evening (that is, for sat 28th i see the evening photos, then the daylight photos including 1975 as expected)

however -- 1990 appears under sunday sept 29 in my timeline. what's more -- sunday sept 29th appears later in the timeline than saturday. that is to say, when i am scrolling from the top of my timeline, i see today, yesterday, et... then sat sept 28, and then sunday sept 29 and then fri sept 27th.

immich version:

i refreshed metadata for all images taken that weekend after installing the update.

i expect to see both these photos appearing under saturday sept 28th, with 1990 appearing above 1975.

separately, i'm not sure where the timeline of africa is coming from -- my server timezone is set to UTC. i guess the UTC offset is correct but thought i would note that. in my env i have TZ="Etc/UTC" . my client is in the pacific timezone

[lgrawet]

Did you configure TZ for your server (to something other than UTC)?

@C-Otto I'm using the timezone setup from the official docker-compose.yml:

services:
  immich-server:
  ...
   volumes:
      # Do not edit the next line. If you want to change the media storage location on your system, edit the value of UPLOAD_LOCATION in the .env file
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
      - /etc/localtime:/etc/localtime:ro
  ...

On the docker host:

s -lh /etc/localtime 
lrwxrwxrwx 1 root root 35 Feb 26  2024 /etc/localtime -> /usr/share/zoneinfo/Europe/Brussels

[jrasm91]

@lgrawet can you upload a sample file, and extected vs actual expectations in a new top level comment?

[jrasm91]

@jrasm91 I don't know if this is intentional. For assets without timezone information, the time is parsed (assuming local time based on TZ) and converted to UTC when storing it in the database. In the detail pane, this time is then also shown as UTC. I believe it should be converted back to the timezone specified by TZ for displaying.

@C-Otto - Assets without timezone information should not show any timezone name/offset in the asset detail panel. The only exception I am aware of, is for videos, which always have a timezone set to UTC (probably a bug).

[C-Otto]

Which time should be shown, though? Currently, it's the local time converted to UTC (i.e. two hours off for me).

[jrasm91]

Which file?

[LittleNewton]

[mmomjian]

I agree with you in theory @alextran1502 but there is currently no good way for users to know which assets require this pre-ingest cleanup. We don't have any option such as "ignore missing timestamp" for CLI or web upload.

[jrasm91]

@LittleNewton - sure, but it's not obvious what/how to do about it and it also isn't trivial to fix either. I'm not saying we won't ever fix it, but that's the current state of things. Thank you for bringing it up and we will update this thread when we have a solution or resolution that problem.

[LittleNewton]

Hi jrasm, I have update to v1.118.1 and the time zone is still wrong. Please derive a right timezone from GPS if there is.

import pathlib
import os
import datetime

imageFolder = 'img' + '/'
File_List = os.listdir(imageFolder)


for picture in File_List:
  # get main name
  filePath = imageFolder + picture
  fileName = pathlib.Path(imageFolder + picture)
  creationTime = str(datetime.datetime.fromtimestamp(fileName.stat().st_ctime))
  baseName = ''
  for char in creationTime:
    if char != ':':
      baseName = baseName + char
  # get extension name
  newName = imageFolder + baseName + '.' + filePath.split('.')[1].lower()
  os.rename(filePath, newName)

I never use the upload functionality inside of immich because I trust my NAS's smb service more than a app and I believe there are a lot of human have the same opinion. Before I moving the photos to immich's external directory, I will use this python script to renaming them.

[LittleNewton]

This python code can derive the exact right SAVED TIME for pictures saved on your phone. The SAVED TIME is the time you save this picture from ins/x/whatsapp to your phone, not the time you press the shutter.

[jrasm91]

ctime is wrong, you can find existing issues about ctime vs mtime. The server only works if the tool that uploads the files sends the correct mtime, and so I have no idea how/where you uploaded the files, but the official cli and mobile app both correctly send this data.

[LittleNewton]

[C-Otto]

I think you're confusing "when" and "where". Just set coordinates if you care about the "where".

[C-Otto]

Here's me in Chile:

The offset is -03:00, but the location is somewhere in the Atacama desert.

[C-Otto]

And here's me in NYC:

[lgrawet]

@jrasm91 @C-Otto Here is one of the problematic picture. Look at "Gps Time Stamp", "Create Date" and file name.

GPS Time Stamp                  : 11:35:40
Create Date                     : 2024:01:18 12:35:41.474573
File name                       : IMG_20240118_123540699.jpg

Thanks to this information you can tell it is 12:35 UTC+1 (CET).
But for Immich :

And for some unknown reason:

File Modification Date/Time     : 2024:01:18 13:35:40+01:00

I've noticed this on the problematic pictures I checked. Not all pictures from this Moto G6 have this particularity and maybe this confuses immich.

IMG_20240118_123540699.zip

[lgrawet]

@C-Otto in this case it is not sharing (I did not test this use case though).
I'm logged into the other user account.
Anyway, I tried refresh from his timeline or from the picture viewer, no improvement.

[lgrawet]

I have launched a full metadata extraction job. Let's see if it fixes the problem.

[lgrawet]

No change after full metadata extraction job, still bad time @C-Otto
And there is no xmp along the jpg file in the library.

[lgrawet]

Hello @C-Otto and @jrasm91
Do you have any information about this issue (metadata extraction not updating dates/times) ?
Thank you!

[lgrawet]

Bug report submitted #14087

[tkp-dev]

I have a number of images with wrong timezone set in-camera. Immich shows datetime and timezones as set in camera. Due to wrong timezone images incorrectly sorted in the Immich timeline.

I'd like to fix wrong timezone in images. But looking at exiftool output for correct (2024-10-05 17-46-36.JPG in-camera timezone +3) and wrong (2024-10-19 14-16-15.JPG in-camera timezone +4) images I can see NO difference - system and maker's both timezone set to +3 and DaylightSavings to Yes.

What image 2024-10-19 14-16-15.JPG tag should I correct for Immich to see it as correct +3, not wrong +4?

.env
TZ=Europe/Vilnius

Daylight Saving TimeEEST: Eastern European Summer TimeCurrently in use | UTC+3
Standard TimeEET: Eastern European Time | UTC+2

Images pack !!!Deleted on update as not related!!!

and their exiftool times:

======== 2024-10-05 17-46-36.JPG
[System]        FileModifyDate                  : 2024:10:13 09:10:35+03:00
[System]        FileAccessDate                  : 2024:10:23 15:00:49+03:00
[System]        FileCreateDate                  : 2024:10:23 14:42:42+03:00
[IFD0]          ModifyDate                      : 2024:10:05 17:46:36
[ExifIFD]       DateTimeOriginal                : 2024:10:05 17:46:36
[ExifIFD]       CreateDate                      : 2024:10:05 17:46:36
[Nikon]         TimeZone                        : +03:00
[Nikon]         DaylightSavings                 : Yes
[Nikon]         DateDisplayFormat               : Y/M/D
[Nikon]         PowerUpTime                     : 2024:10:05 17:46:32
[ExifIFD]       SubSecTime                      : 50
[ExifIFD]       SubSecTimeOriginal              : 50
[ExifIFD]       SubSecTimeDigitized             : 50
[GPS]           GPSTimeStamp                    : 14:46:36
[GPS]           GPSDateStamp                    : 2024:10:05
[Composite]     SubSecCreateDate                : 2024:10:05 17:46:36.50
[Composite]     SubSecDateTimeOriginal          : 2024:10:05 17:46:36.50
[Composite]     SubSecModifyDate                : 2024:10:05 17:46:36.50
[Composite]     GPSDateTime                     : 2024:10:05 14:46:36Z
======== 2024-10-19 14-16-15.JPG
[System]        FileModifyDate                  : 2024:10:19 22:41:07+03:00
[System]        FileAccessDate                  : 2024:10:23 15:00:49+03:00
[System]        FileCreateDate                  : 2024:10:23 14:51:56+03:00
[IFD0]          ModifyDate                      : 2024:10:19 14:16:15
[ExifIFD]       DateTimeOriginal                : 2024:10:19 14:16:15
[ExifIFD]       CreateDate                      : 2024:10:19 14:16:15
[Nikon]         TimeZone                        : +03:00
[Nikon]         DaylightSavings                 : Yes
[Nikon]         DateDisplayFormat               : Y/M/D
[Nikon]         PowerUpTime                     : 2024:10:19 14:16:08
[ExifIFD]       SubSecTime                      : 40
[ExifIFD]       SubSecTimeOriginal              : 40
[ExifIFD]       SubSecTimeDigitized             : 40
[GPS]           GPSTimeStamp                    : 11:16:15
[GPS]           GPSDateStamp                    : 2024:10:19
[Composite]     SubSecCreateDate                : 2024:10:19 14:16:15.40
[Composite]     SubSecDateTimeOriginal          : 2024:10:19 14:16:15.40
[Composite]     SubSecModifyDate                : 2024:10:19 14:16:15.40
[Composite]     GPSDateTime                     : 2024:10:19 11:16:15Z
    2 image files read

[tkp-dev]

Did some research and found out the answers. There were actually two problems.

1. Wrong time zone were set as UTC+3, actually it was UTC+2 & Daylight saving +1. Fixed time zone with exiftool -Nikon:TimeZone+=-60 *.nef *.jpg

2. Not in these photos but other Daylight saving in this specific Nikon D7000 camera were incorrectly set to Yes always, while it should be set to No during the non Daylight saving periods. I thought ON in the settings means AUTO. not the case, so in Nikon you need to set correct time zone by non Daylight saving period and then manually switch Daylight Savings ON/OFF depending on period of the year. Now need to fix a lot of previous images to correct Daylight Savings settings to have them in correct order in the Immich (ang gphotos as well). Same as with TimeZone above should work.

[bcirceprime]

Image: Christmas Tree
Expected Date: Monday, December 11, 2023 at 5:14 PM EST
Date in Immich: 06/01/2024 07:41PM (time zone is +00:00) (NOTE This is the "modified" date/time of the image)

IMG_0245.JPG.zip

[bcirceprime]

Here is another example but I am not going to zip it,

Here is the meta data I see pre-zip

Then, after zip/unzip, i see this:

Which leads me to believe, something is getting lost in the zip/unzip. Which, to be fair, I have never heard of a Zip modifying data like that.

[bcirceprime]

Here is that file zipped for your reference
IMG_0600.JPG.zip

[bcirceprime]

Here is the metadata viewer I am using https://pics.io/photo-metadata-viewer

[bo0tzz]

Try using https://exif.tools/ (or just actual exiftool on your system) instead, so you're using the same tooling that Immich is.

[snuq]

zipping a file will not change the metadata as that is stored in the binary file data itself, but it WILL mess with the file dates (normally stored in the file system not the file). specifically, the 'created date' does not get stored in a zip at all. see my post above: #12650 (reply in thread) for more info.
it IS possible to store the created date in a 7z file, but 7zip will not store it by default (needs ann extra option to be added).

[Koli0842]

I have some timezone oddities trying to move my ~20k asset library into Immich. I am in CEST +2:00/+1:00 depending on DST, which is where most of my photos are created. Except my current phone, Pixel 7, all my media show up 1 to 2 hours (depending on DST) ahead of where they should be, while still detecting and displaying the timezone correctly. My older phones are Pixel (1), Axon 7, Nexus 5, all the way back to a Sony Ericsson W595, and digital cameras. I manually added timezone info to the digital camera and "dumbphone" photos with Exiftool, and now they behave the same. It's like the time was interpreted as UTC and the timezone offset was applied on top of it.

Example EXIF data from a Pixel 7 photo that works correctly:
DateTimeOriginal 2023:05:26 22:01:22
CreateDate 2023:05:26 22:01:22
OffsetTime +02:00
OffsetTimeOriginal +02:00
OffsetTimeDigitized +02:00
ModifyDate 2023:05:26 22:01:22
FileCreateDate 2023:05:26 22:01:22+02:00
FileModifyDate 2023:05:26 22:01:22+02:00

Showing up correctly as 2023. máj. 26. P 22:01 GMT+2:00

Example EXIF data from a Pixel 1 that does not work correctly (this one has untouched exif data)
DateTimeOriginal 2023:05:26 21:11:14
CreateDate 2023:05:26 21:11:14
OffsetTime +02:00
OffsetTimeOriginal +02:00
OffsetTimeDigitized +02:00
ModifyDate 2023:05:26 21:11:14
FileCreateDate 2023:05:26 21:11:14+02:00
FileModifyDate 2023:05:26 21:11:14+02:00

Showing up incorrectly as 2023. máj. 26. P 23:11 GMT+2:00. This photo shows a clock at 21:11 and was taken before the previously mentioned, I took both when I bought my new phone. I am fairly lost at what could be wrong. I uploaded each of my asset with immich-go. I attached both of the example photos.

I have another unrelated issue too, I have some old camcorder / digital camera video recordings in .mp4, .avi and .mpg files. I cannot see any time related metadata on them, with exiftool, avi metaedit, or various file managers and video players. Even if there was, it should be months off, as I know time was not set correctly on these devices and file creation dates were off by months. I adjusted file creation dates with NirSoft's bulk file changer to line up correctly. When I upload these files to immich, they get converted to UTC, correctly, so they receive UTC as timezone info and are 2 hours earlier than my local timezone they were recorded in. I have seen a flag in code which would suggest this is intended, but why convert to UTC when it looks like there is timezone info available (judging from how it made a correct conversion in my case)? Is there any way to convert photos to a given timezone, without adjusting the clock and timezone one by one?

[C-Otto]

On my server the Pixel 1 photo (IMG_20230526_211114.jpg) shows up as 21:11 GMT+02:00, which I'd say is correct. I'm using v1.120.1. The other photo also shows the correct time (22:01 GMT+02:00).

[Koli0842]

You're right. Looks like it was a mistake from me to assume Immich-Go doesn't mess with the timestamps and it's handled on the backend entirely, it very much does; uploading the same file from immich-go and the web UI results in a difference in how times are handled. I'll take my issue to their repo. Thanks!

[sycorax]

Hello,
I also have time problems with some of my old photos. Some appear from 2050 and some from 1980. They are in an external library. I attach 2 samples for analysis. A bug fix would be greatly appreciated. Thanks

expected date: 2010.08.09, Bucharest timezone

expected date: 2011.08.21, UTC+01 timezone

photos.zip

[johndoe0815]

Paris (241018-190101).zip

The photo has been taken on an iPhone at 19:01 CET in Paris, France. It is shown like that in Lightroom, and based on that the Lightroom export has also put the time in the filename.

ExifTool also shows 19:01:

But Immich puts the file at 18:01:

I have tried to set the TZ env variable, but that does not change anything.
As this issue only occurs for the iPhone pictures but not for the one of my DSLR, pictures in my album are now ordered in completely wrong sequence. This issue does only occur in Immich and is obviously on timezones.

[C-Otto]

As also visible on your screenshot, the OffsetTime is set to +01:00. Do you know where this value came from?

[johndoe0815]

I further investigated and played around, and it looks like indeed actually Lightroom messes that up, not Immich. I just did not have this situation before.
Instead of just ignoring and not touching the OffsetTime, Lightroom on Windows actually seems to set it to the time zone of the computer it runs when exporting. As the picture was taken during summer time and I exported it in Lightroom during winter time, it changes the OffsetTime from +2 to +1!
I manually adjusted the time zone on my computer, and then the OffsetTime gets exported correctly and the time is also displayed in Immich correctly.

So it is obviously a bug in Lightroom. There is also a very old discussion here, where someone mentions it would be resolved in the current version, but it isn't :-(
https://community.adobe.com/t5/lightroom-classic-discussions/p-lightroom-should-preserve-offsettime-attribute-in-dng-files/m-p/6429833

So this is not directly an issue of Immich, but an issue with Lightroom in the situation where picture was taken in summer time but export was done in winter time. Bad Adobe!

[johndoe0815]

After reading a bit more, I think that it actually is an issue with Immich.
As per EXIF definition (https://exiftool.org/TagNames/EXIF.html), OffsetTime is the timezone of the last modification date. But this is not what Immich uses. Immich seems to use the DateTimeOriginal (seems to be confirmed also in #6459 (comment)).
And DateTimeOriginal has the timezone set in OffsetTimeOriginal, which still correctly is +2:00, like you can see in the screenshot above.
So wouldn't you also think that this is a bug with Immich, considering the wrong field?

[C-Otto]

This is data provided by exiftool-vendored, photostructure/exiftool-vendored.js#220

[luisdralves]

Hey, I'm getting a weird issue when I have a sequence of photos where some have GPS data and some don't. I'm not sure which of the two is resolving incorrectly, but it seems that photos with GPS get their timestamp converted to the local timezone, while photos without GPS are in UTC. This leads to incorrect ordering.

As an example, here are two photos, one of which has GPS data. They were both taken in Amsterdam (UTC+1). As their filenames imply, they were taken 1 hour apart, however, immich assigns them the same time. The opposite also happens: photos taken immediately one after the other get timestamps 1 hour apart.

IMG_20221126_1.zip

Example with GPS

---- ExifTool ----
ExifTool Version Number         : 13.04
Warning                         : [minor] Unknown APP5 segment
Warning                         : [minor] Unknown APP6 segment
Warning                         : [minor] Unknown APP7 segment
Warning                         : [minor] Unknown APP8 segment
---- System ----
File Name                       : IMG_20221126_125706_390.jpg
Directory                       : .
File Size                       : 13 MB
File Modification Date/Time     : 2024:12:04 12:52:38+00:00
File Access Date/Time           : 2024:12:04 12:53:02+00:00
File Inode Change Date/Time     : 2024:12:04 12:53:02+00:00
File Permissions                : -rw-r--r--
---- File ----
File Type                       : JPEG
File Type Extension             : jpg
MIME Type                       : image/jpeg
Exif Byte Order                 : Little-endian (Intel, II)
Image Width                     : 8000
Image Height                    : 6000
Encoding Process                : Baseline DCT, Huffman coding
Bits Per Sample                 : 8
Color Components                : 3
Y Cb Cr Sub Sampling            : YCbCr4:2:0 (2 2)
---- IFD0 ----
Image Description               : 
Make                            : Ulefone
Camera Model Name               : Power Armor 13
Orientation                     : Horizontal (normal)
X Resolution                    : 72
Y Resolution                    : 72
Resolution Unit                 : inches
Software                        : MediaTek Camera Application
Modify Date                     : 2022:11:26 12:57:05
Y Cb Cr Positioning             : Co-sited
Exif 0x0220                     : 0
Exif 0x0221                     : 0
Exif 0x0222                     : 0
Exif 0x0223                     : 0
Exif 0x0224                     : 0
Exif 0x0225                     : 
---- ExifIFD ----
Exposure Time                   : 1/60
F Number                        : 1.8
Exposure Program                : Not Defined
ISO                             : 105
Sensitivity Type                : Unknown
Recommended Exposure Index      : 0
Exif Version                    : 0220
Date/Time Original              : 2022:11:26 12:57:05
Create Date                     : 2022:11:26 12:57:05
Components Configuration        : Y, Cb, Cr, -
Shutter Speed Value             : 1/59
Brightness Value                : 0
Exposure Compensation           : 0
Max Aperture Value              : 1.0
Metering Mode                   : Center-weighted average
Light Source                    : Other
Flash                           : Off, Did not fire
Focal Length                    : 1.8 mm
Sub Sec Time                    : 865
Sub Sec Time Original           : 865
Sub Sec Time Digitized          : 865
Flashpix Version                : 0100
Color Space                     : sRGB
Exif Image Width                : 8000
Exif Image Height               : 6000
Exposure Mode                   : Auto
White Balance                   : Auto
Digital Zoom Ratio              : 1
Focal Length In 35mm Format     : 0 mm
Scene Capture Type              : Standard
---- InteropIFD ----
Interoperability Index          : R98 - DCF basic file (sRGB)
Interoperability Version        : 0100
---- GPS ----
GPS Version ID                  : 2.2.0.0
GPS Latitude Ref                : North
GPS Latitude                    : 52 deg 18' 35.57"
GPS Longitude Ref               : East
GPS Longitude                   : 4 deg 45' 47.65"
GPS Altitude Ref                : Above Sea Level
GPS Altitude                    : 41 m
GPS Time Stamp                  : 11:57:00
GPS Processing Method           : CELLID
GPS Date Stamp                  : 2022:11:26
---- IFD1 ----
Compression                     : JPEG (old-style)
Orientation                     : Horizontal (normal)
X Resolution                    : 72
Y Resolution                    : 72
Resolution Unit                 : inches
Thumbnail Offset                : 1408
Thumbnail Length                : 49792
Y Cb Cr Positioning             : Co-sited
Thumbnail Image                 : (Binary data 49792 bytes, use -b option to extract)
---- Composite ----
Aperture                        : 1.8
Image Size                      : 8000x6000
Megapixels                      : 48.0
Shutter Speed                   : 1/60
Create Date                     : 2022:11:26 12:57:05.865
Date/Time Original              : 2022:11:26 12:57:05.865
Modify Date                     : 2022:11:26 12:57:05.865
GPS Altitude                    : 41 m Above Sea Level
GPS Date/Time                   : 2022:11:26 11:57:00Z
GPS Latitude                    : 52 deg 18' 35.57" N
GPS Longitude                   : 4 deg 45' 47.65" E
Focal Length                    : 1.8 mm
GPS Position                    : 52 deg 18' 35.57" N, 4 deg 45' 47.65" E
Light Value                     : 7.5

Example without GPS

---- ExifTool ----
ExifTool Version Number         : 13.04
Warning                         : [minor] Unknown APP5 segment
Warning                         : [minor] Unknown APP6 segment
Warning                         : [minor] Unknown APP7 segment
Warning                         : [minor] Unknown APP8 segment
---- System ----
File Name                       : IMG_20221126_115706_335.jpg
Directory                       : .
File Size                       : 12 MB
File Modification Date/Time     : 2024:12:04 12:52:48+00:00
File Access Date/Time           : 2024:12:04 12:53:02+00:00
File Inode Change Date/Time     : 2024:12:04 12:53:02+00:00
File Permissions                : -rw-r--r--
---- File ----
File Type                       : JPEG
File Type Extension             : jpg
MIME Type                       : image/jpeg
Exif Byte Order                 : Little-endian (Intel, II)
Image Width                     : 8000
Image Height                    : 6000
Encoding Process                : Baseline DCT, Huffman coding
Bits Per Sample                 : 8
Color Components                : 3
Y Cb Cr Sub Sampling            : YCbCr4:2:0 (2 2)
---- IFD0 ----
Image Description               : 
Make                            : Ulefone
Camera Model Name               : Power Armor 13
Orientation                     : Horizontal (normal)
X Resolution                    : 72
Y Resolution                    : 72
Resolution Unit                 : inches
Software                        : MediaTek Camera Application
Modify Date                     : 2022:11:26 11:57:06
Y Cb Cr Positioning             : Co-sited
Exif 0x0220                     : 0
Exif 0x0221                     : 0
Exif 0x0222                     : 0
Exif 0x0223                     : 0
Exif 0x0224                     : 0
Exif 0x0225                     : 
---- ExifIFD ----
Exposure Time                   : 1/265
F Number                        : 1.8
Exposure Program                : Not Defined
ISO                             : 102
Sensitivity Type                : Unknown
Recommended Exposure Index      : 0
Exif Version                    : 0220
Date/Time Original              : 2022:11:26 11:57:06
Create Date                     : 2022:11:26 11:57:06
Components Configuration        : Y, Cb, Cr, -
Shutter Speed Value             : 1/264
Brightness Value                : 0
Exposure Compensation           : 0
Max Aperture Value              : 1.0
Metering Mode                   : Center-weighted average
Light Source                    : Other
Flash                           : Off, Did not fire
Focal Length                    : 1.8 mm
Sub Sec Time                    : 128
Sub Sec Time Original           : 128
Sub Sec Time Digitized          : 128
Flashpix Version                : 0100
Color Space                     : sRGB
Exif Image Width                : 8000
Exif Image Height               : 6000
Exposure Mode                   : Auto
White Balance                   : Auto
Digital Zoom Ratio              : 1
Focal Length In 35mm Format     : 0 mm
Scene Capture Type              : Standard
---- InteropIFD ----
Interoperability Index          : R98 - DCF basic file (sRGB)
Interoperability Version        : 0100
---- IFD1 ----
Compression                     : JPEG (old-style)
Orientation                     : Horizontal (normal)
X Resolution                    : 72
Y Resolution                    : 72
Resolution Unit                 : inches
Thumbnail Offset                : 1408
Thumbnail Length                : 49792
Y Cb Cr Positioning             : Co-sited
Thumbnail Image                 : (Binary data 49792 bytes, use -b option to extract)
---- Composite ----
Aperture                        : 1.8
Image Size                      : 8000x6000
Megapixels                      : 48.0
Shutter Speed                   : 1/265
Create Date                     : 2022:11:26 11:57:06.128
Date/Time Original              : 2022:11:26 11:57:06.128
Modify Date                     : 2022:11:26 11:57:06.128
Focal Length                    : 1.8 mm
Light Value                     : 9.7

Is there any batch operation I can do in the web interface or in the DB to fix this? I care only about the order, both timestamp interpretations are fine by me.

[luisdralves]

I tried explicitly setting the timezone with exiftool -ExifIFD:OffsetTimeDigitized=+01:00 -ExifIFD:OffsetTimeOriginal=+01:00 -ExifIFD:OffsetTime=+01:00 *.jpg before uploading and it seems to have fixed the issue. I suppose there's not much more immich can do — without the GPS information or the user specifying it, there's no way to guess the timezone. Unless it can be configured to ignore GPS altogether? Like I said, to me only the order is important, the accuracy not so much.

[luisdralves]

Unfortunately, this approach does not seem to work for videos. From what I've read, it seems that if no GPS data is present, immich assumes that the timestamps are in the same timezone as the TZ env var, correct? In my case it is set as Europe/Lisbon which is the same as UTC during winter, and could explain the behaviour above.

Alas, I just checked a Portuguese album and it is also affected. This seems to imply that UTC is assumed, regardless of the TZ env var. If anyone has any idea, I would appreciate some help.

[neal421]

I have an issue where photos uploaded from today show up as yesterday. This seems to be a common problem, and I am also new to immich.

[dinosmm]

Hello,

I am not sure if this thread is meant for my issue but here goes.
I am on v1.122.2 and I am only using an external library.
I have the issue where some days within a month are shown out of order. The photos all have correct metadata, and Immich shows all photos within the correct day, so e.g. every picture that has metadata for 28/7/2024 shows under 28th July 2024. That's fine.

But the 28th July section itself, is shown in the wrong place. My timeline is ordered in reverse, so as I scroll, going down to July, it starts with:

28th
31st
30th
29th
27th
26th
25th
24th
16th
13th
18th
19th
23rd
22nd
21st
20th
15th
14th
12th
9th
11th
10th
7th
5th
6th
8th
4th
3rd
2nd
1st

I am attaching a zipped photo. This photo is showing under the correct day section.
20240731_202116.jpg.zip

[raimundmeyer]

I have the same problem. I just went through all photos of the year and it happens frequently that e.g. you have the holiday pictures then some from before the holiday and you keep scrollling and suddenly there's the holidy again. But apparently now the photos from another camera or mobile.

Here are two Fotos, one of December 23 and one of December 29, which appears surprisingly between 22th and 23th. The timestamps shown in Immich seem correct and they were both taken with the same camera.
immich-20241212_202526.zip

[MrToiz]

Hello,
new immich user here. I just noticed that while photos from my wife's phone (Google Pixel 6a) are shown with their correct timestamp, the ones from my phone (Huawei P30lite) are off by exactly the timezone difference.
Both files have been manually post-processed with EXIF tool to contain correct timezone information, to the best of my knowledge.

a zip of your file

IMG_20241007_153809.zip

the expected date, including timezone

07-October-2024, 15:38:09+02:00

current date produced by immich

07-October-2024, 17:38:09+00:00

immich version:

v122.2

immich timezone:

Europe/Amsterdam (equals +02:00 for the given date)

EXIF data

Thanks so far,
MrToiz

[MrToiz]

It gets even stranger. I've noticed that when I upload the files directly from my (Huawei) phone, the time is shown correctly in Immich. Only my manual post-processing with exiftool seems to break it. However, when comparing the EXIF data, nothing wrong seems to be added.

IMG_20241210_154920_original.txt
IMG_20241210_154920_after_postprocessing.txt

Any idea what could cause the issue?

[rlue]

Can any of the devs speak to how immich derives time zones when dealing with video files? I have my own home-rolled photo/video import utility and I'd like to configure it to generate identical timestamps (for filenaming purposes) to the ones that immich would for any given input file.

For photos, this seems to be lifted directly from the DateTimeOriginal exif tag with a fallback to CreatedAt (src?). AFAIU this is generally assumed to be local time, even if you're utilizing the OffsetTimeOriginal exif tag to explicitly store the time zone.

With video, on the other hand, my experience has been that timestamps are always stored in UTC (unless the device you shot it on has no way of knowing what time zone you're in): e.g., if you shoot a video at noon in Shanghai, your phone will record the timestamp as 4a, while your GPS-less digital camera would just record the timestamp as noon. Then, AFAICT, immich will do its best to combine that UTC timestamp with GPS metadata on the video to adjust for your local timezone. So even if the timestamp says 4a (UTC), immich will look up the UTC offset for Shanghai (+8) and use YYYY-mm-dd 12:00:00 for the filename.

My questions:

1. Is this logic stable, or still subject to change? If I set up my home-rolled import scripts to mimic what immich does here, is it safe to assume that immich will still be doing the same thing in six months or a year?
2. Which video metadata tags does immich look at to determine the time zone of the video? I'm thinking I'd like to artificially add these tags to videos prior importing them if they're ever missing. (The files I've inspected so far include both GPSLatitude/GPSLongitude and Location/LocationInformation.)

Thanks in advance, I'm so impressed with immich and with the team's engagement with the community. 🙇🏻🙇🏻🙇🏻

[pagdot]

The video attached is from a 3ds. It's metadata is a bit weird, but it has an exif block containing the creation date+time starting at byte 0x4EC, although exiftool isn't able to find the block because it seems to be at a weird position in the file

• Date of the metadata: 2024-12-21 12:10:47 (local time of the 3DS)
• Date in immich: Whatever the filesystem modified timestamp is, as exiftool isn't able to find the metadata

I'd suggest to add an alternative fallback to the timestamp: filename. Some devices store the date in the filename and it is very easy to store it there without having to modify the actual file. e.g. My phone stores image as IMG_yyyymmdd_hhmmss.jpg. I've already created a script to read the date from the file because I don't like the file structure for pictures from the 3DS.

HNI_0015.zip