Can I ask why, when it is the `[EXIF] Date/Time Original’ that used to be exported along with other EXIF tags but, now seems to have been omitted.
Simply adding this EXIF tag back in will solve the problem without the need for polluting the XMP namespace with IPTC metadata.
We’re on it
Is there any way to roll back to the last version of PL 5.1? To me that was the last time that PL behaved well. I know they are now aware of this problem so we should see a fix in the foreseeable future but right now I find it just maddening. I have some cameras that the time is off, others that it is still accurate. I have some files that export with the correct date and time, some with the correct date and shifted time, some that export with the export date and time.
I really would like a way to install 5.1 and just wait it out.
Yes, provided you’ve a) kept the DPL 5.1 installer or b) have a backup, e.g. Time Machine.
The Finder relies on the Composite:DateTimeCreated to display the Content Creation date. This is derived from IPTC:DateTimeCreated, so this is what we are planning to export when the EXIF checkbox is checked
If I might be so annoying as to say…
I just did a test.
I chose a file that was showing the “Contenu Créé” value in Finder as today (when I exported it)…
I checked to see what Composite:DateTimeCreated returned…
joannacarter@MacBookPro Desktop % exiftool -composite:datetimecreated IMG_1857_DxO.jpg
(nothing)
I set exif:dateTimeOriginal to some fictional date in the past…
joannacarter@MacBookPro Desktop % exiftool -exif:dateTimeOriginal="2005:10:23 20:06:34.33-05:00" IMG_1857_DxO.jpg
1 image files updated
I look at the file in Finder…
And yet, Composite:DateTimeCreated still returns nothing.
So, it seems like you only need to write the appropriate EXIF tag and not the IPTC one 
I am the OP and as promised here is an update on the support ticket. I was asked to upgrade to version 5.3 and test to see if it fixed the problem. It did not.
The request to do the upgrade and to re-test an export said that it came from “the developers”. I tend to have my doubts about that since the development team has responded here and stated that the fix would not be in the next update. That or the ticket is being worked completely independently of the problems outlined here (even though I included a link to this thread in the ticket).
@sgospodarenko would it be possible for you to see if my service ticket (362564) is being handled by the team that is actually looking at this problem?
[Apologies for hijacking this thread for what turns out to be a different but related issue!]
I suspect something similar is happening with image creation times in the XMP sidecar if metadata sync is on. I just turned it back on having upgraded to 5.3.0, and soon turned it off again - other apps reading the XMPs after PL had saved changes were seeing creation dates changed by my local time zone offset, which is +10:00. I think this used to work correctly with PL 5.1. I haven’t had time to dig into what is changed yet, but I will do so. I’m using a variety of Panasonic cameras.
Update: I just did a quick before-and-after comparison using Exiftool. The XMP before PL has changed it has:
[XMP-exif] Date/Time Original : 2022:06:15 07:32:06.701
After changing the star rating in PL, it has:
[XMP-exif] Date/Time Original : 2022:06:14 21:32:06.7-00:00
So PL is adjusting the time to UTC and adding a zero timezone offset that was not there before, and the other apps fail to adjust for that - they assume this field is ‘local time’ even in the presence of the zero time offset.
Looking at the raw with Exiftool, which in this case is from a Panasonic TZ220, I see these related items:
[Composite] Create Date : 2022:06:15 07:32:06.701+10:00
[Composite] Date/Time Original : 2022:06:15 07:32:06.701+10:00
[Composite] Modify Date : 2022:06:15 07:32:06.701+10:00
[ExifIFD] Create Date : 2022:06:15 07:32:06
[ExifIFD] Date/Time Original : 2022:06:15 07:32:06
[ExifIFD] Offset Time : +10:00
[ExifIFD] Offset Time Digitized : +10:00
[ExifIFD] Offset Time Original : +10:00
[IFD0] Modify Date : 2022:06:15 07:32:06
Maybe the other apps are reading ExifIFD:CreateDate and ignoring the OffsetTime that goes with it, but PL is being more rigorous, and since the offset time is missing in the XMP, PL assumes UTC.
Or it could be that since the EXIF CreateDate spec seems to be ‘string’ rather than ‘date’, PL is wrong to add a timezone offset to it.
Or I could have read this wrong, and it’s something else!
Either way, I still can’t use metadata sync.
And another update: if I change the shot time in PL by adding 10 hours, it shows up at the right time in my other apps. The XMP file then contains the right time (according to the other apps), with a zero time offset, like this:
[XMP-exif] Date/Time Original : 2022:06:15 07:32:06.7-00:00
Alternatively, just adding my local timezone offset (+10:00) to the Date/Time Original instead of +00:00 fixes it. PL should be getting that from the operating system, or allowing me to specify it.
Using an idea triggered by @Europat’s comment in this thread, I have found that running PL with its app timezone set to GMT seems to sort things out for the XMPs - on a Mac, this means I have to use this command in a terminal window to start PL:
TZ=GMT open /Applications/DXOPhotoLab5.app
More testing is needed, but I don’t think this workaround will allow me to leave Metadata Sync on if I am to access any images PL originally saw with my correct local timezone.
Updated yet again: It appears that if PL creates the XMP file in the first place, rather than another app, it works as it should. This led me to creating the XMPs and adding the timezone of the image to DateTimeOriginal using Exiftool at import time (for which I use a script anyway), and this seemed to provide a workaround for my particular circumstances - but it doesn’t survive back-and-forth changes between the apps (PL and Mylio, in my case).
Good morning!
Regards,
Svetlana G.
Thank you so much for this 5.3.1 release!
Thank you!
Thank you!
Thank you!
Merci!
Merci!
Merci!
Today’s release (5.3.1) fixes the time/date issue.
I had actually stopped processing anything because I didn’t want my date data messed up. I just tested some older files that previously (since v5.2) reported the export date as date taken. They now report the date taken correctly.
I know that this problem did not effect all files and all cameras so it was not an issue for everyone. Thank you to the DxO team for getting this issue handled quickly. I posted a ticket only sixteen days ago. Today the problem is fixed. That is just unheard of today.
Thank you also to @Joanna for stepping up and providing technical data more complex than what I was able to provide. I feel certain that your contribution here helped escalate the issue and helped the DxO staff understand what was actually happening.
Merci to @sgospodarenko for getting this to the correct staff members and for letting me know the status of my help ticket.
DxO Pl is a stellar product and the support staff is top notch.
My related sidecar issue is also fixed in this release. Thank you, DxO team!
I can confirm that I am now seeing the same exif:DateTimeOriginal in an exported JPEG as is found in the original RAW file.
Good work.
Unfortunately, I am finding this to NOT be the case.
The clock drift occurs in the dateTimeOriginal EXIF tag and only in images that were made on a mobile device. The drift error is the same number of hours between the TZ in which the image was made and the TZ in which it was exported; e.g. 6 hours earlier for an image made in CEST and exported in US ET (UTC+2 vs. UTC-4).
Exports for the createDate EXIF tag are correct.
If someone wants some images to work on to verify or track down this behavior, please reach out.
I still need to test images that were made in and exported in my home TZ.
Test 2 - Different mobile device (same manufacturer), photos made and post-processed in same TZ:
dateTimeOriginal is correct and in agreement with createDate.
ETA - It’s not just TZ, it’s manufacturer and TZ. A third test with images made on a different mobile device and with mixed time zones exported correctly.
Motorola is the one where it’s only partially working (in the createDate EXIF tag). Something in the Motorola EXIF elsewhere is causing problems for PL5.
Do you want to send me a file to look at?
Sure, how would I do that?
Just post it here
I take it this is not the original file, but an export. I need to see the original file as well please
