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.
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.
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.
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.
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.
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
??