You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe what problem this solves and why this would be valuable to many users
Importing files sorts into folders based on UTC: YYYY/MM/YYYY-MM-DD_HHMMSS_HASH.EXT. This is confusing on the boundary between days with timezones being considered as images can wind up in the wrong month and year.
Example from google Pixel phone. PXL_20231231_220232177.jpg taken on the morning of Jan 1st 2024, went "missing" because it was sorted into Dec 31st, 2023.
It correctly sees the UTC+11 offset, and doesn't change anything about what the file reports its local time as, but it sorts it by UTC+0 meaning this photo winds up in the "wrong" year and month folder structure. See also #4035.
I understand why we would choose to store the UTC in the filename, and in fact the attached pixel image has also done so, but I think when it comes to an organizational layout, people aren't going to be thinking about their lookup based on UTC/GMT, they'll be thinking about it based on the local time the image was taken.
Describe the solution you'd like
I'd suggest the folder these are sorted into should be based on the image's local time, not UTC. I have no strong opinion on whether the filename remains UTC or not.
Perhaps this is user configurable? #475 certainly touches on some of this. but I'm not sure is really the same feature request. I think the ability to change the directory structure is fundamentally different to an uncertainty on how we should populate the YYYY-MM in the current date based structure.
Describe alternatives you've considered
Not using the import tool and writing my own to process my import files into a photoprism like structure and naming, with the folder sorting based on local time. This would lose me the ability to quickly weed out duplicates and keep the originals folder only containing unique images, which was one of the main reasons I started using photoprism. Not really a great option!
Could also write a custom script to run over the originals folder with exiftool and reorganise them after an import, and then reindex, but this will be somewhat tedious!
Additional context
2024-01-26 11:29:07 INFO import: added main jpg file 2023/12/20231231_220232_CAB7AA8A.jpg
2024-01-26 11:29:07 INFO media: 20231231_220232_CAB7AA8A.jpg was taken at 2023-12-31 22:02:32.177 +0000 UTC (meta)
2024-01-26 11:29:07 INFO metadata: PXL_20231231_220232177.jpg has time offset UTC+11 (exiftool)
2024-01-26 11:29:07 INFO media: created 11 thumbnails for 2023/12/20231231_220232_CAB7AA8A.jpg [1.785522953s]
2024-01-26 11:29:05 INFO metadata: PXL_20231231_220232177.jpg has time offset UTC+11 (exiftool)
2024-01-26 11:29:05 INFO import: moving main jpg file PXL_20231231_220232177.jpg to 2023/12/20231231_220232_CAB7AA8A.jpg
2024-01-26 11:29:05 INFO media: PXL_20231231_220232177.jpg was taken at 2023-12-31 22:02:32.177 +0000 UTC (meta)
The text was updated successfully, but these errors were encountered:
rickdoesdev
changed the title
Category: Import Folder Structure
Category: Import Folder Structure to use Local time instead of UTC
Jan 26, 2024
rickdoesdev
changed the title
Category: Import Folder Structure to use Local time instead of UTC
Import Folder Structure to use Local time instead of UTC
Jan 26, 2024
Describe what problem this solves and why this would be valuable to many users
Importing files sorts into folders based on UTC: YYYY/MM/YYYY-MM-DD_HHMMSS_HASH.EXT. This is confusing on the boundary between days with timezones being considered as images can wind up in the wrong month and year.
Example from google Pixel phone. PXL_20231231_220232177.jpg taken on the morning of Jan 1st 2024, went "missing" because it was sorted into Dec 31st, 2023.
It correctly sees the UTC+11 offset, and doesn't change anything about what the file reports its local time as, but it sorts it by UTC+0 meaning this photo winds up in the "wrong" year and month folder structure. See also #4035.
I understand why we would choose to store the UTC in the filename, and in fact the attached pixel image has also done so, but I think when it comes to an organizational layout, people aren't going to be thinking about their lookup based on UTC/GMT, they'll be thinking about it based on the local time the image was taken.
Describe the solution you'd like
I'd suggest the folder these are sorted into should be based on the image's local time, not UTC. I have no strong opinion on whether the filename remains UTC or not.
Perhaps this is user configurable? #475 certainly touches on some of this. but I'm not sure is really the same feature request. I think the ability to change the directory structure is fundamentally different to an uncertainty on how we should populate the YYYY-MM in the current date based structure.
Describe alternatives you've considered
Not using the import tool and writing my own to process my import files into a photoprism like structure and naming, with the folder sorting based on local time. This would lose me the ability to quickly weed out duplicates and keep the originals folder only containing unique images, which was one of the main reasons I started using photoprism. Not really a great option!
Could also write a custom script to run over the originals folder with exiftool and reorganise them after an import, and then reindex, but this will be somewhat tedious!
Additional context
The text was updated successfully, but these errors were encountered: