Solve a timezone adjustment problem in XMP sidecar files
What problem do you see this solving?
Describe the problem or issue you are having in Capture One.
Think about what it is that you're trying to achieve, and the reason why you are trying to do it.
When was the last time you were affected by this lack of functionality, or specific tool?
If your feedback is more general, simply let us know how much your workflow is affected.
Are you using any workarounds or other solutions to achieve your goals in Capture One?
This is so we have a greater understanding of how your workflow is affected, and how we can improve the existing tools and functionality.
Are you happy to be contacted further about this suggestion or request?
Let us know with a simple “Yes” or “No” – we will contact you with the email address used in your Capture One profile.
-
Sorry - don't know what happened there. I had described the issue....here goes again:
Capture One seems to do things differently in XMP sidecar files when it comes to recording and interpreting the time and date. Specifically, the timezone offset, if present in the raw file metadata. It makes it very difficult to work with multiple applications and update rating and color tag - those are the tags that cause C1 to update the XMP sidecar file. Here is an example: image captured in Singapore with a Nikon Z7 II, set to the correct timezone which is UTC + 8 hours. Actual capture time is 12:00. After C1 imports the file, there is no XMP sidecar file yet. After updating either rating or color tag, C1 creates an XMP file with a date time entry. If I use another app, like DxO Photolab 6, to change rating or color tag, that date time entry changes to include the timezone offset information. C1 upon syncing metadata then ignores that timezone offset and so things the capture time is 20:00 -- moving it 8 hours forward. Messes up smart albums, filters, etc....
There is a workaround of changing time back again.
Happy to be contacted on the issue.
thanks
Jan-Peter
0 -
Yes, C1 messes up timezone offsets. I have a support ticket with multiple ways to reproduce the issue and many proofs of it, it took a long time to have the problem be understood (which I hope they did, instead of just shoving my ticket into a forgotten drawer). The ticket hasn't have any updates in months.
Ticket #182624, opened 6 months ago.
1 -
I have experienced this same problem now. Capture One is recording the DateTimeOriginal in the XMP file with a Z appended to the end, which indicates it is in UTC. But the time being put there is not UTC, it is the time with the offset. This screws up sorting of images when edited with external applications that read the DateTimeOriginal from the XMP file. And this completely trashes my multiple application workflow. Can we please get this resolved sooner than later. The fact someone already has a support ticket from four months ago identifying this problem and it has still not been solved is unacceptable.
3
Please sign in to leave a comment.
Comments
3 comments