[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?

[r01k]

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

Yes, this is a known and common issue.

[C-Otto]

#15634

[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

[C-Otto]

I think this is fixed in #15650 (not yet released, might end up in v1.125.3 or v1.126.0). Feel free to report back with any insights you might have!

[C-Otto]

You can fix this yourself by re-running the metadata extraction job. This needs to be done everytime an asset is marked as offline (and online) again, at least until the fix mentioned above is released.

[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?

[MrToiz]

I'm now at Immich v1.124.2 and somthing has changed. If I delete one of the old photos with wrong timestamp and upload it again, the correct timestamp is detected!

However, I have spent quite some time organizing the photos into albums and tagging faces. Is it somehow possible to just redetect the timestamps? I have tried the "Refresh metadata" for a single image as well as the "Extract metadata" background task for the whole library, but without effect :( Any hints?

[C-Otto]

The image you provided (cute) shows up as 15:38 +02:00, which matches the filename. I don't see any issue with that.

In your postprocessing tags, the "TimeZone" tag is added. I believe this is meant to describe the time zone (offset) at which you edited the file, and should not be used as the "real" time zone (offset). I recently opened photostructure/exiftool-vendored.js#220 because of this, so this might be fixed soon.

If you run the "extract metadata" job, it should do exactly what you need. However, because of the issue mentioned above, the code might detect the wrong time zone offset. Could you provide a file for which the result is wrong after running the metadata refresh job?

[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. 🙇🏻🙇🏻🙇🏻

[C-Otto]

The "what's the date/time/zone for that asset?" question is far more complicated than the "src?" you linked at. We're using the "exiftool-vendored" library which parses exif tags, applies some heuristics and deals with all kinds of weirdness. We fall back to the file's modification date (or creation date, if that's earlier), if we can't find helpful metadata.

With video it's always UTC, yes. See photostructure/exiftool-vendored.js#113

The logic is far from stable, simply because the topic of date/time/zone/offset is extremely complicated, and because device vendors have bugs (or interesting interpretations of standards). We'll do our best to make things work out of the box, which is also why we're having this "megathread".

[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

[HOCHH4U5JUMP3R]

Is there any option to just disable timezones completely or shut down the date/time mess? I literally have to go through every uploaded file and either change timezone manually as it is UTC now or correct date and time completely, then see all photos again as some (shot with iPhone for example) have correct date/time, but then a screenshot for example gets UTC and is not sorted correctly with the other photos that do have Europe/Berlin. I have more than 40k assets, it's a compete mess since I had to move over from my old NAS to my new one and thought I just reupload all images/videos and sort out some old and unnecessary ones instead of just putting everything to the new NAS.
Immich Version is latest (1.123.0) coming from v1.110.0 and I have the feeling it worked way better on that old version :(

Here is one example of thousands:
It's a screenshot taken 8th of July 2020 02:59:26, it even has the date & clock on it so we can be sure it was this exact moment.
MacOS sets filenames with that timestamp, so the file is named by automation "Bildschrimfoto [Date YYYY-MM-DD] um [Time HH.MM.SS].png" in this case it is "Bildschirmfoto 2020-07-08 um 02.59.26.png"

I live in Europe/Berlin timezone this is also what I have given the .env file as TZ variable, but it seems to not matter at all.
Expectation would be: 8th of July 2020 02:59 (GMT+2:00) Europe/Berlin

This screenshot uploaded to immich results in 7th of July 2020 20:59 which is -6 hours off to the correct timestamp.
So immich has gotten the correct time of that image somewhere, and then magically decided to subtract 6 hours and set the wrong timestamp in a pseudo UTC.
It's not 6 hours off on every image, sometimes it's 8hours, I have pictures with 2 hours and 4 hours even 1 hour offsets aswell. Those are taken on the same locations too, so I'm clueless what immich does with the times at all.
But as it somehow gathers the information correctly in the first place (I assume otherwise it could not possibly guess the minutes correct each and everytime) I would like to just get rid of that magic part and use the thing it gathers initially, is that somehow possible?

Archiv.zip

[HOCHH4U5JUMP3R]

Thanks for checking, can you by chance have a look at attached file I took 2 days ago, it uploads showing 12.01.2025 19:23 UTC
Each screenshot is UTC, and the newer ones seem to be off by 1 or 2 hours depending on summer/winter time..
Screenshot from Archiv.zip was already uploaded to my old immich installation and downloaded from there, reuploaded to another immich instance with new version, might caused some trouble with the dates in the file idk...

Thank you in advance!

[luisdralves]

Sorry, I would need it zipped in order to check. Github must be doing some processing to uploaded images. However, you can also easily check for yourself. exiftool, the command I used above, has a GUI program which is simple to set up.

https://exiftool.org/gui/

[HOCHH4U5JUMP3R]

Ah I understand, I did check on my own now and here is some interesting result:

On the right is my old installation of immich (v1.110.0) on the left the new version (v1.123.0) and in the middle the exiftool with the infos. As we can see the old immich matched perfectly fine with correct date and time and timezone, the new version messed it up and changed the time 1 hour backwards (subtraction of the timezone) and made it UTC...

config files are exactly the same, even copied .env file contents to make absolutely sure.

[luisdralves]

Very interesting! It looks like there may have been a regression of some kind between those versions. We will have to wait for someone more knowledgeable to chime in.

[C-Otto]

The file does not contain any time zone offset information. Older versions of Immich assumed the configured time zone (TZ) for these assets, which is what you see on the right hand side of your screenshot. Newer versions do the same, but the implicit time zone is not shown, anymore. Instead, the TZ value is used to derive the correct "absolute" time (with time zone offset information), which then is shown as UTC (without any time zone offset information in the GUI). This way you, as a user, can see that no time zone information is available, and you're free to add it manually. See #12779

[JoshuaSeidel]

is there any actual fix for this? searching reddit and google, looks like the app not honoring the TZ has been around for over a year...

[bo0tzz]

This thread isn't a particular issue to be fixed. It's a place to collect any cases of time handling seeming off in a structured way, to avoid having a large amount of (usually wrong) individual bug reports. If you have a specific example of the handling being wrong, please post the info listed in the OP.

[dinosmm]

I'm not sure if my issue is the same as those discussed here, but...

I thought I'd fixed it by removing my external library and re-adding it one folder at a time, allowing Immich to scan the folder before adding the next one. This seemed to work, and there was no jumbling up!

However, I rebooted the server today, and the issue returned. The storage didn't come online before Immich did, which resulted in Immich showing no photos (but the database was intact, this is stored locally). I brought the storage online and restarted Immich, then I had to rescan the external library and the date headings were jumbled up again.

There doesn't seem to be an issue with reading incorrect EXIF data or anything like that. The correct date-taken is read and shown on Immich, and Immich puts the photos under the correct date heading. It's just that the headings themselves are jumbled up.

[C-Otto]

I think this is fixed in #15650 (not yet released, might end up in v1.125.3 or v1.126.0). Feel free to report back with any insights you might have!

[GITHUBNULLING]

I’m using DJI devices (Pocket 3, Action 3) to record videos, but the timestamps of the videos in Immich are incorrect. I’m in the GMT+8 timezone, but the videos are incorrectly recognized as UTC, so the time hasn’t been properly adjusted by +8 hours. However, photos taken with the DJI devices display the correct timestamps. I’m not sure whether this is an issue with the DJI device metadata or if Immich is not handling the dates properly. I’ve tested one of the devices by recording both videos and photos, packaged the files, and included screenshots showing the dates generated by Immich.


immich_timezone_mismatch.zip

[rgarcia246810]

I am having the same issue with DJI pocket 3. The way I have Immich set up is through an external library which is managed by synology photos. Long story short, the metadata is correct when viewed through synology photos, but showing up with a UTC time zone whenever viewed through immich. Therefore, I don't believe it is an issue with dji metadata. I also have videos from a gopro and those appear with a utc time zone as well. Worth noting pictures viewed on immich have the correct time zone which for me is GMT-8

[C-Otto]

For videos timezone information is extremely unrealiable, which is why all videos default to UTC. Related: photostructure/exiftool-vendored.js#113

[pingu8007]

(Referred from #15404 - it's an false alarm)

I tried to import my photo libraries into Immich and the timeline is a mess. I finally realized that my rx100m3 never wrote the timezone offset into photos even it has such configuration in the menu.

Before I messing around, I'd like to know

• can Immich drop all changes in database and reload everything from EXIF metadata? I tried to rerun the metadata tasks but nothing changed.
• can Immich modify the date/time and timezone separately? It seems Immich always save both fields, it make the batch change function hard to use.
• I found updating geo location also update the date/time and timezone, can those be unlinked? (It tried to preserve the epoch timestamp, and it's fine if the date/time is correct)

---

If all of above are no, do you think the following feature are considerable?

• add checkboxes in front of date/time and timezone and only update checked fields on save.
• add checkbox after geo location and only update date/time and timezone together if checked (checked by default).

Further more it will be great if

• add a menu item that reload everything from EXIF
• add a timezone picker in user profile that specific default timezone if not available from exif (or use browser/device timezone)

Those feature are still conceptional and open to discussion

[C-Otto]

If you run the metadata extraction job, the date is read from the file's exif tags (if they exist). Any existing XMP sidecar file takes precedence, though. If this doesn't work, your files might not contain metadata - feel free to upload examples here (zipped).

To change just the offset I wrote a small script that creates XMP files. That's not a very elegant approach, though. Short answer: no, not really possible.

Location and timezone are linked, so I don't see why these should be decoupled. If a location exists, it is used to infer timezone information. This cannot be turned off.

If you configure the TZ environment variable, this time zone is used/assumed for files that do not have any timezone metadata.

The features might be reasonable, feel free present implementation ideas!

[pingu8007]

Do you mean the timezone is determined in this order?

1. XMP sidecar
2. EXIF timestamp offset
3. EXIF geo location
4. TZ env var
5. Fallback to UTC

[thomasss02]

I have an issue with whatsapp photos.
Real date: 2025/01/19 9.56 GMT+1
Fake date 1601/01/01 01.01 GMT+1

I attach the file

[thomasss02]

Exiftool output
ExifTool Version Number : 13.12
File Name : IMG-20250119-WA0027.jpg
Directory : C:/Users/Thomas/Downloads/exiftool-13.12_64
File Size : 1088 kB
File Modification Date/Time : 2025:01:19 09:56:36+01:00
File Access Date/Time : 2025:01:19 16:18:57+01:00
File Creation Date/Time : 2025:01:19 16:18:56+01:00
File Permissions : -rw-rw-rw-
File Type : JPEG
File Type Extension : jpg
MIME Type : image/jpeg
JFIF Version : 1.01
Resolution Unit : None
X Resolution : 1
Y Resolution : 1
Image Width : 3024
Image Height : 4032
Encoding Process : Progressive DCT, Huffman coding
Bits Per Sample : 8
Color Components : 3
Y Cb Cr Sub Sampling : YCbCr4:2:0 (2 2)
Image Size : 3024x4032
Megapixels : 12.2

[C-Otto]

When I import the asset, I get 2025-01-19 14:53 (without any time zone information), which is somewhat correct. What's the issue you're seeing? Where does the 1601 date come into play?

[Trainax]

Hello. I'm having some problems with timezones only on the Android app. The time and date is correct, however it's the wrong timezone.

1. Example photo in a ZIP file: IMG_20241229_123615.zip
2. Expected date, including timezone: 29/12/2024 12:36 (UTC +01:00 Europe/Rome)
3. Current date produced by immich: 29/12/2024 12:36 (UTC +01:00 Africa/Algiers)

I have set Europe/Rome as TZ inside the immich .env file. This only happens on mobile (Android in my case), on the web interface it correctly shows Europe/Rome.

Web	Mobile

Thanks!

[bo0tzz]

This is normal, we don't store the string part, it's the same timezone though.

[Trainax]

This is normal, we don't store the string part, it's the same timezone though.

Would it be possible to instead also store the string part and automatically assign the same TZ as the one set in the .env file if the time matches?

Like if the photo embedded date data says 29/12/2024 UTC +01:00 without specifying which specific timezone and the set TZ in the .env file is also a UTC +01:00 timezone then assign the timezone which is set via .env file to the photo.

Thanks again

[C-Otto]

It's not possible to store more time zone (offset) information than the numerical offset ("+01:00" etc.). However, the web page prefers the value configured in TZ if it has the same offset as the asset, which is why you see Europe/Rome instead of any of the other "+01:00" options. A similar feature might be possible for the apps.

[C-Otto]

Related: #5897

[denisjoshua]

Hi there all,
I'm new on Immich and I have just installed on a docker in my server.

Here is my date problem... I always edit the TAG using the Digikam and in base of TAG I make my albums.
But if I edit the TAG on a set of pictures using Digikam, when that pictures is refresh in Immich the pictures is on the today page.
Can this be solve in some mode please ?
Thanks
Denis

[C-Otto]

I understand that you modify the file (using another application) which then causes Immich to show these files at a different date (namely, the time of the change). If you want to fix the date, you should either include metadata in the file itself (exif), or manually edit the date once so that this information is persisted in a sidecar XMP file.

[C-Otto]

HST is UTC-10. The photo was taken at 14:50 local time on the 22nd, which is after midnight UTC on the 23rd. It might be possible that the timeline uses UTC at this place, and from UTC's point of view the photo was taken a day before. I'll investigate.

[C-Otto]

Yes, that's the issue. The comparison confuses the local time (without any time zone information, assuming UTC) and the correct local time. This results in wrong comparison results, and wrong output ("yesterday").

[C-Otto]

web/src/lib/utils/timeline-util.ts:98

[C-Otto]

See #15634

[ckuyehar]

It's a confirmed bug; see #15634.