immich-app/immich
1
0
Fork 0
mirror of https://github.com/immich-app/immich.git synced 2026-02-05 00:30:57 +03:00
Code Issues 11 Packages Projects Releases 10 Wiki Activity

[BUG] strorage migration job doesn't take timezone value from TZ env #647

New Issue
Closed
opened 2026-02-04 21:40:20 +03:00 by OVERLORD · 20 comments
OVERLORD commented 2026-02-04 21:40:20 +03:00
Owner
Copy Link

Originally created by @MichaelBui on GitHub (Feb 2, 2023).

Originally assigned to: @jrasm91 on GitHub.

Describe the bug
As seen below, 221026_103248.heic is the filename generated by Immich storage migration job:

❯ exiftool -j 221026_103248.heic | grep DateTime
  "DateTimeOriginal": "2022:10:26 18:32:48",
  "ProfileDateTime": "2022:01:01 00:00:00",
  "SubSecDateTimeOriginal": "2022:10:26 18:32:48.809+08:00",

and it's generated without taking timezone value from TZ env (see below) into account:

/usr/src/app # env | grep TZ
TZ=Asia/Singapore

Task List

Please complete the task list below. We need this information to help us reproduce the bug or point out problems in your setup. You are not providing enough info may delay our effort to help you.

  • I have read thoroughly the README setup and installation instructions.
  • I have included my docker-compose file.
  • I have included my redacted .env file.
  • I have included information on my machine, and environment.

To Reproduce
Steps to reproduce the behavior:

  1. Set TZ env for the docker container
  2. Run the Immich apps (db, server, web,...) then configure the path template with both date & time
  3. Log into the container, verify that the TZ env is set correctly
  4. Run the storage migration job & wait until it finish
  5. Check the filename & compare with EXIF info & TZ value to see the mismatch

Expected behavior
Filename generated by the storage migration job should use timezone value from TZ env

Screenshots
If applicable, add screenshots to help explain your problem.

System

  • Phone OS [iOS, Android]: <version>
  • Server Version: v1.42.0
  • Mobile App Version: <version>

Additional context
Similar functionality has been implemented here: https://github.com/immich-app/immich/pull/618

Originally created by @MichaelBui on GitHub (Feb 2, 2023). Originally assigned to: @jrasm91 on GitHub. <!-- Note: Please search to see if an issue already exists for the bug you encountered. --> **Describe the bug** As seen below, `221026_103248.heic` is the filename generated by Immich storage migration job: ``` ❯ exiftool -j 221026_103248.heic | grep DateTime "DateTimeOriginal": "2022:10:26 18:32:48", "ProfileDateTime": "2022:01:01 00:00:00", "SubSecDateTimeOriginal": "2022:10:26 18:32:48.809+08:00", ``` and it's generated without taking timezone value from `TZ` env (see below) into account: ``` /usr/src/app # env | grep TZ TZ=Asia/Singapore ``` **Task List** *Please complete the task list below. We need this information to help us reproduce the bug or point out problems in your setup. You are not providing enough info may delay our effort to help you.* - [x] I have read thoroughly the README setup and installation instructions. - [ ] I have included my `docker-compose` file. - [ ] I have included my redacted `.env` file. - [x] I have included information on my machine, and environment. **To Reproduce** Steps to reproduce the behavior: 1. Set `TZ` env for the docker container 2. Run the Immich apps (db, server, web,...) then configure the path template with both date & time 3. Log into the container, verify that the TZ env is set correctly 4. Run the storage migration job & wait until it finish 5. Check the filename & compare with EXIF info & TZ value to see the mismatch **Expected behavior** Filename generated by the storage migration job should use timezone value from `TZ` env **Screenshots** If applicable, add screenshots to help explain your problem. **System** - Phone OS [iOS, Android]: `<version>` - Server Version: `v1.42.0` - Mobile App Version: `<version>` **Additional context** Similar functionality has been implemented here: https://github.com/immich-app/immich/pull/618
OVERLORD added the 🗄️server label 2026-02-04 21:40:20 +03:00
OVERLORD commented 2026-02-04 21:40:34 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Feb 3, 2023):

We don't use the timezone of the container anymore, it is inferred by the exif-vendor library

@alextran1502 commented on GitHub (Feb 3, 2023): We don't use the timezone of the container anymore, it is inferred by the exif-vendor library
OVERLORD commented 2026-02-04 21:40:38 +03:00
Author
Owner
Copy Link

@MichaelBui commented on GitHub (Feb 3, 2023):

@alextran1502 if it doesn't use the timezone from TZ, I guess it's using the system's timezone value? How should I configure the system to have this desired filename 221026_183248.heic (local) instead of 221026_103248.heic (UTC)?

I'm running TrueNAS-SCALE-22.12.0 (k3s) with a timezone selected (set to TZ value) for the deployment/pod

@MichaelBui commented on GitHub (Feb 3, 2023): @alextran1502 if it doesn't use the timezone from `TZ`, I guess it's using the system's timezone value? How should I configure the system to have this desired filename `221026_183248.heic` (local) instead of `221026_103248.heic` (UTC)? I'm running `TrueNAS-SCALE-22.12.0` (k3s) with a timezone selected (set to `TZ` value) for the deployment/pod
OVERLORD commented 2026-02-04 21:40:41 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Feb 3, 2023):

@MichaelBui hmm this is an interesting problem since the file is uploaded and moved to the corresponding location before the EXIF extraction corrected the timezone.

@alextran1502 commented on GitHub (Feb 3, 2023): @MichaelBui hmm this is an interesting problem since the file is uploaded and moved to the corresponding location before the EXIF extraction corrected the timezone.
OVERLORD commented 2026-02-04 21:40:51 +03:00
Author
Owner
Copy Link

@MichaelBui commented on GitHub (Feb 3, 2023):

During the upload, the TZ is used, hence the correct filenames but once the storage migration is running, all files are converted to OS timezone.
We can try to install tzdata for our docker images but since the uploading process is using TZ, it will be consistent to use TZ for the storage migration job as well

@MichaelBui commented on GitHub (Feb 3, 2023): During the upload, the TZ is used, hence the correct filenames but once the storage migration is running, all files are converted to OS timezone. We can try to install `tzdata` for our docker images but since the uploading process is using `TZ`, it will be consistent to use `TZ` for the storage migration job as well
OVERLORD commented 2026-02-04 21:40:56 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Feb 3, 2023):

@jrasm91 Any thoughts on this?

@alextran1502 commented on GitHub (Feb 3, 2023): @jrasm91 Any thoughts on this?
OVERLORD commented 2026-02-04 21:41:01 +03:00
Author
Owner
Copy Link

@jrasm91 commented on GitHub (Feb 3, 2023):

The date specified during upload is more of a hint, since we fully rely on the time returned from exiftool-vendored library to finalize the datetime for the picture. To see how it calculates the date and factors in timezones, see: https://github.com/photostructure/exiftool-vendored.js#dates.

Do these images not have any timezone, offset, or gps tags included in the exif?

@jrasm91 commented on GitHub (Feb 3, 2023): The date specified during upload is more of a hint, since we fully rely on the time returned from exiftool-vendored library to finalize the datetime for the picture. To see how it calculates the date and factors in timezones, see: https://github.com/photostructure/exiftool-vendored.js#dates. Do these images not have any timezone, offset, or gps tags included in the exif?
OVERLORD commented 2026-02-04 21:41:07 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Feb 4, 2023):

Can you help confirm that the timezone in the file when viewed on either the web or mobile is correct?

@alextran1502 commented on GitHub (Feb 4, 2023): Can you help confirm that the timezone in the file when viewed on either the web or mobile is correct?
OVERLORD commented 2026-02-04 21:41:11 +03:00
Author
Owner
Copy Link

@akoen commented on GitHub (Apr 15, 2023):

I can confirm that the timezone in the stored file is incorrect, while on the web it is correct. This happens to all my files.

image

@akoen commented on GitHub (Apr 15, 2023): I can confirm that the timezone in the stored file is incorrect, while on the web it is correct. This happens to all my files. ![image](https://user-images.githubusercontent.com/43913902/232177078-a8808bdc-e028-49ec-92ea-2bc7e8c93324.png)
OVERLORD commented 2026-02-04 21:41:16 +03:00
Author
Owner
Copy Link

@sadrov commented on GitHub (May 15, 2023):

@akoen @alextran1502 I stumbled upon the same problem. I noticed that when I go into the immich_server container's CLI and do a 'date' command, it only lists the UTC time.
I'm in the CEST timezone so doing the same command in the CLI of my server (so not in the docker containers) I get a 2 hour offset compared to the time of immich_server.
When I check the time details in web or app it is displayed correctly according to my timezone. The file that lives in the library folder however has a UTC timestamp.
image
image

Can I conclude that the storage template always looks at Universal time and the local system time is always ignored?
Is this by design? I would expect the timestamp in the filenames to be matching with the time the pic was taken to more easily find photos of a certain time when browsing outside of the image UI.

Great work on the whole project btw, I'm really loving it!

@sadrov commented on GitHub (May 15, 2023): @akoen @alextran1502 I stumbled upon the same problem. I noticed that when I go into the immich_server container's CLI and do a 'date' command, it only lists the UTC time. I'm in the CEST timezone so doing the same command in the CLI of my server (so not in the docker containers) I get a 2 hour offset compared to the time of immich_server. When I check the time details in web or app it is displayed correctly according to my timezone. The file that lives in the library folder however has a UTC timestamp. ![image](https://github.com/immich-app/immich/assets/44714129/3b16ea7a-2460-48c7-84dc-8c57a06598ef) ![image](https://github.com/immich-app/immich/assets/44714129/05135883-f0ba-473e-8e73-3ef6bbf9ebf3) Can I conclude that the storage template always looks at Universal time and the local system time is always ignored? Is this by design? I would expect the timestamp in the filenames to be matching with the time the pic was taken to more easily find photos of a certain time when browsing outside of the image UI. Great work on the whole project btw, I'm really loving it!
OVERLORD commented 2026-02-04 21:41:25 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (May 15, 2023):

@sadrov I believe this happened because we are not using the exif date data for the template but use the file creation time instead, so the timezone isn't taking into consideration here

@alextran1502 commented on GitHub (May 15, 2023): @sadrov I believe this happened because we are not using the exif date data for the template but use the file creation time instead, so the timezone isn't taking into consideration here
OVERLORD commented 2026-02-04 21:41:31 +03:00
Author
Owner
Copy Link

@sadrov commented on GitHub (May 15, 2023):

Thanks @alextran1502 for your quick reply! It makes sense.
When I browse the files on the iphone directly (connected by usb), in the DCIM folder the creation time of the file shows correct, but maybe that's just Windows displaying it with the 2 hour offset to match the timezone?
image
Would it make sense to request the feature to also have the option of using the exif date in the storage template? I believe nextcloud did that by default.

@sadrov commented on GitHub (May 15, 2023): Thanks @alextran1502 for your quick reply! It makes sense. When I browse the files on the iphone directly (connected by usb), in the DCIM folder the creation time of the file shows correct, but maybe that's just Windows displaying it with the 2 hour offset to match the timezone? ![image](https://github.com/immich-app/immich/assets/44714129/e47dcfb5-7448-42e1-b921-6b2df60af28d) Would it make sense to request the feature to also have the option of using the exif date in the storage template? I believe nextcloud did that by default.
OVERLORD commented 2026-02-04 21:41:42 +03:00
Author
Owner
Copy Link

@jrasm91 commented on GitHub (May 15, 2023):

I believe we use exif date, we just are using the UTC timestamp, not the TZ adjusted version of it.

@jrasm91 commented on GitHub (May 15, 2023): I believe we use exif date, we just are using the UTC timestamp, not the TZ adjusted version of it.
OVERLORD commented 2026-02-04 21:41:50 +03:00
Author
Owner
Copy Link

@sadrov commented on GitHub (May 15, 2023):

ok cool, I understand now where the time offset comes from and that it is intended this way and not something wrong on my side.
Thanks a lot for the answers

@sadrov commented on GitHub (May 15, 2023): ok cool, I understand now where the time offset comes from and that it is intended this way and not something wrong on my side. Thanks a lot for the answers
OVERLORD commented 2026-02-04 21:41:55 +03:00
Author
Owner
Copy Link

@jrasm91 commented on GitHub (May 16, 2023):

It might be easy enough to add options here so that it uses the timezone information if available.

https://github.com/immich-app/immich/blob/main/server/libs/domain/src/storage-template/storage-template.core.ts#L152

@jrasm91 commented on GitHub (May 16, 2023): It might be easy enough to add options here so that it uses the timezone information if available. https://github.com/immich-app/immich/blob/main/server/libs/domain/src/storage-template/storage-template.core.ts#L152
OVERLORD commented 2026-02-04 21:42:05 +03:00
Author
Owner
Copy Link

@sadrov commented on GitHub (May 16, 2023):

I'm not so comfortable with adjusting source code and compiling but I guess it could be nice to try when I have some spare time :)
Thanks for your answer!

@sadrov commented on GitHub (May 16, 2023): I'm not so comfortable with adjusting source code and compiling but I guess it could be nice to try when I have some spare time :) Thanks for your answer!
OVERLORD commented 2026-02-04 21:42:08 +03:00
Author
Owner
Copy Link

@jrasm91 commented on GitHub (May 16, 2023):

If you're not comfortable, I can give it a try later.

@jrasm91 commented on GitHub (May 16, 2023): If you're not comfortable, I can give it a try later.
OVERLORD commented 2026-02-04 21:42:10 +03:00
Author
Owner
Copy Link

@sadrov commented on GitHub (May 17, 2023):

that would be awesome, thank you so much :D

@sadrov commented on GitHub (May 17, 2023): that would be awesome, thank you so much :D
OVERLORD commented 2026-02-04 21:42:18 +03:00
Author
Owner
Copy Link

@uhthomas commented on GitHub (Jul 11, 2023):

Possibly resolved by #2908?

@uhthomas commented on GitHub (Jul 11, 2023): Possibly resolved by #2908?
OVERLORD commented 2026-02-04 21:42:23 +03:00
Author
Owner
Copy Link

@ryny24 commented on GitHub (Oct 29, 2024):

Is this fixed? I am running v1.119.0 and I've spent hours trying to set my timezone. I've added TZ=America/New_York to .env. I've restarted with -d and --force-recreate. But all newly added photos are GMT. I've tried quotes around the timezone. I've searched the docs and can't figure out how to fix this.

@ryny24 commented on GitHub (Oct 29, 2024): Is this fixed? I am running v1.119.0 and I've spent hours trying to set my timezone. I've added TZ=America/New_York to .env. I've restarted with -d and --force-recreate. But all newly added photos are GMT. I've tried quotes around the timezone. I've searched the docs and can't figure out how to fix this.
OVERLORD commented 2026-02-04 21:42:35 +03:00
Author
Owner
Copy Link

@jrasm91 commented on GitHub (Oct 29, 2024):

Can you open a new bug? This might be a regression.

@jrasm91 commented on GitHub (Oct 29, 2024): Can you open a new bug? This might be a regression.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
accessibility
changelog:enhancement
changelog:security
changelog:translation
cli
date-time
documentation
external-library
format
good first issue
needs-answer
nice to have
sharing
tech-debt
📱mobile
🖥️web
🗄️server
🧠machine-learning
No Label 🗄️server
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#647
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?