Repository navigation
fix(import): name date folders by local capture date, not UTC - #2137
Open
mandishshah wants to merge 1 commit into
Open
mandishshah wants to merge 1 commit into
mandishshah wants to merge 1 commit into
Conversation
Since CyberTimon#1632 the EXIF capture time is resolved as local time and returned as DateTime<Utc>, but import_files still formatted the "organize by date" subfolder from the UTC value. West of UTC, evening photos landed in the next day's folder; east of UTC, early-morning photos in the previous day's. Convert to Local before formatting, as generate_filename_from_template already does. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Since #1632,
get_creation_date_from_path/get_creation_date_from_bytescorrectly treat an offset-less EXIFDateTimeOriginalas local wall-clock time and return it as aDateTime<Utc>. That fixed export timestamps, butimport_filesstill formats the Organize by date subfolder straight from that UTC value, so the folder is the UTC calendar date.West of UTC this files every evening photo into the next day's folder. With the system timezone set to America/Los_Angeles:
2026:11:06 17:39:21(PST)2026/11-072026/11-062026:09:21 17:39:21(PDT)2026/09-222026/09-21(East of UTC, early-morning photos go to the previous day.) The filename template was not affected, because
generate_filename_from_templatealready converts withwith_timezone(&chrono::Local), so a{YYYY}{MM}{DD}filename and its folder could disagree by a day.Type of Change
Changes Made
import_files(desktop and Android branches): convertfile_datetochrono::Localbefore formatting the date subfolder, matchinggenerate_filename_from_template.Screenshots/Videos
Not applicable.
Testing
What was checked:
cargo fmt -p RapidRAW -- --checkpasses.cargo clippy --all-targets -- -D warningspasses on macOS, apart from one pre-existing, unrelated lint insrc/apple_raw.rs(chunks_exact_to_as_chunks) that also fails onmainwith the pinned 1.98 toolchain.creation_datetime_to_utcplus the old and new formatting, chrono 0.4.45) was run withTZset to America/Los_Angeles, Pacific/Honolulu, UTC, Asia/Kolkata and Pacific/Auckland for evening, late-night, just-after-midnight and DST-change capture times. The old code files photos one day late west of UTC and one day early east of UTC (e.g.2026:02:15 00:00:01→2026/02-14in Asia/Kolkata); with the fix every case lands in the capture date's folder.Test Configuration:
Checklist
Additional Notes
Libraries already imported with an affected version can have photos one folder off (evening shots west of UTC, early-morning shots east of UTC); this PR only changes new imports and does not move existing files.
AI Disclaimer:
🤖 Generated with Claude Code