Support for manually editing capture time
(taken from the What’s Next page)
Related:
Edit: this topic used to also reference editing title, and description/caption, but this feature has been split out here: Support viewing and editing Title and Description
Mass-edit would be useful, here. With digicams that do not, like modern smartphones, set their clocks automatically via NTP, it’s common to have an entire series of images with incorrect timestamps, with a consistent offset to correct–particularly just after daylight saving time change or physical transport of the camera to another time zone (“oh, no–I was in Central for that whole shoot, but my camera was still set to Pacific time”).
(Cameras using UTC internally, like any rationally-designed computing device does, would likely solve much of this. Grumblegrumblegrumble.)
I currently use a Windows program called “Exif Date Changer” for this purpose. My wedding photographer used two cameras, and one of them was set incorrectly, making it impossible for me to put my photos in chronological order. With Exif Date Changer, I was able to select all of the photos taken by the camera with the bad date, and then specify an offset to change them all to the correct time.
If Photostructure could (eventually) do that, awesome!
Hi, first post here.
Just my 2c: I love the fact that PS is an organized view of my photo library. But, at least in the beginning, I don’t think editing should be pursued that much. It’s good to have a best-in-class read-only experience while leaving the editing work to something else.
In my case all the editing is done via DigiKam and PS syncs with it nicely (sidecar files included).
DigiKam date editing is pretty powerful too.
I’m not terribly concerned about date editing in particular. However, I think the BEST time to add titles and descriptions is when you’re browsing the files organically like I often do with Photostructure. If I know that in order to add a title or description I have to find that file and open it in another piece of software, then I’m not going to bother.
The same goes for manual tagging, which is by far the feature upgrade I am most looking forward to.
With respect, I think making Photostructure read-only would be a hindrance to adoption, especially as a paid product.
Just for the sake of completeness I wasn’t suggesting to keep PS read-only (that’s why I said “at least in the beginning”). I could definitely see value in that were PS can write back to sidecar files (or EXIF or both) but being able to share and view via a web interface is still very high in my (personal) priorities. That’s mainly because I found that editing/tagging on a different software (and having the freedom to do so) it’s a huge deal. I’m sure that from the PS point of view more features will attract more (paying?) user so all is good (I’m using 0.9.1 since a few weeks so my experience is limited).
Can’t wait to see what’s coming out for 1.0 
Oh man, I can’t tell you how many assets in my library are borked due to this.
In fact, I changed how PhotoStructure stores captured-at time in the database, (back in v0.6), to be time-zone agnostic, rather than storing everything in UTC, which caused issues due to (most) videos and many images not having reasonable timezone offsets.
The “local centiseconds” is an actual numeric value but with base-10-positional values. Right now, in my time, it’s 2021032818361231, or 2021-03-28 at 6:36pm.
Please note, that if you want to modify file’s EXIF dates via ExifTool, for mov/mp4 files you have to set the setting -api QuickTimeUTC=1 otherwise it will process timezones incorrectly QuickTimeUTC. For other files such setting has no effect, so it’s harmless to use it all the time.
BTW, it’s not datetime related but I remembered also for video files it makes sense to set another ExifTool setting -api LargeFileSupport=1. Otherwise you won’t be able to set EXIF tags for files over 2gb (or maybe 4gb, I didn’t check exactly) LargeFileSupport
@mnaoumov thanks for those tips!
I hadn’t been bit by either of those as I write to sidecars by default, but there is a setting to directly write to originals that should include these flags. I’ll fix this in a future release.
Meh, it was a handful of lines to add this support, so I just did it now.
Given that this is a prerequisite to Support for manually editing tags, are you prioritizing this in spite of the lower vote count?
Yup, this feature is a prerequisite, and it’s a much better defined task.
What I’m getting at is that this has only 8 votes, while Support for manually editing tags has 13 votes and is the 4th-highest open feature request. I’m wondering if you’re going to skip working on this until it’s closer to the top of the requested features, or if you’re taking into account that the other request is already close to the top.
Basically I REALLY want this and I’m curious how long I’m going to be waiting for it 
There are several features hiding in this one topic:
Editing the captured-at time is a bit of a bugaboo: if there are any assetfile variants that aren’t currently mounted, PhotoStructure can’t update their sidecar with the new date, and on next sync, it may shove the variant into a new asset.
Title/description/caption support is a prerequisite for full-text asset search (currently search only looks at a couple asset flags and the captured-at time).
I think it was a mistake to have them all in one topic: oops!
I’ll split out the title/description support into a new topic.
Gotcha… so which of these is a prerequisite for manually editing tags?
Any/all of these features require me to build out “asset transform” support, where each “transform” is
With this information, PhotoStructure can then aggregate and “replay” the transforms at sync time to a given asset.
We need insert, delete, replace to handle fields that are arrays, like keywords.
We need the previous value to detect if the asset has been changed by another tool. If the value isn’t what PhotoStructure expects as per the existing transforms, it won’t apply that transform.
This mechanism allows PhotoStructure to reliably determine what value “wins” for a given set of asset file variants, and allows external apps to “override” what’s been done in PhotoStructure.
(I had an initial version that just wrote the title to a sidecar, but then when I plugged in an older hard drive with a bunch of higher-resolution originals and RAW files, those were picked as the “primary” variant, and they didn’t have my changes, so it “removed” all that work).
I see. With that in mind, how are you prioritizing the “asset transform support” since it’s not an actual feature request, just an underlying prerequisite? Do you tackle it when the first feature request that requires it bubbles to the top of the list? Do you aggregate the votes for all feature requests that require it and use that as your prioritization metric? Should we create a feature request for “asset transform support” and direct people to vote for that in order to get these other requests off the ground?
Infrastructure will never be voted on: I build stuff out when it’s required.
As far as prioritization, I’m not going to be able to strictly follow top-voted features, given that so many features actually require other features: I’m using it as a general guideline to judge interest.
Another example of prerequisite features: if I want to implement sharing, I need album support. Albums will be implemented as hierarchical keyword tags, so manual keyword editing needs to be done. Ideally, bulk asset selection will be supported as well, but it’s not a hard prereq for sharing.