PL 5.2 Changes creation date and time to current on export on some files

I know that this has been discussed in a couple of other threads. I finally took the time to do enough investigating to submit a ticket for support. Just to keep the community informed I will post the same information as I did in the ticket here. Maybe someone here understands exif data batter than I do and will spot the problem.

This only started happening with PL 5.2, I run it on an M1 Mac running Monterey.
Change in file date and/or time in export.

Since release 5.2.0 PhotoLab changes some exif data on export so that the capture date is reported incorrectly in some other software. Not all cameras and files are affected.

On files from my Canon G5X the problem is consistent. Here is an example:

File 20220330-215222_IMG_0766_dxo.jpg was exported under PL 5.1.3. With this file the date taken reports correctly.

File 20220330-215222_IMG_0766_dxo-1.jpg is a new export from the same raw file and was exported using PL 5.2.0. With this file the date taken read by other software is the date of the export.

I compared the EXIF data for both files. You can see all of the EXIF in the attached files but here are extracts containing all of the time information I could fined. Differences are highlighted (were, they don’t paste in):

From PL 5.1.3
File name: 20220330-215222_IMG_0766_dxo.jpg (ExifTool)

Composite <<<
SubSecCreateDate : 2022:03:30 21:52:22.89
SubSecDateTimeOriginal : 2022:03:30 21:52:22.889
SubSecModifyDate : 2022:04:04 17:31:17-04:00

EXIF <<<
CreateDate : 2022:03:30 21:52:22
DateTimeOriginal : 2022:03:30 21:52:22
ModifyDate : 2022:04:04 17:31:17
OffsetTime : -04:00
Software : DxO PhotoLab 5.1.3

File <<<
FileAccessDate : 2022:06:07 10:00:44-04:00
FileInodeChangeDate : 2022:04:11 09:22:29-04:00
FileModifyDate : 2022:04:11 09:16:36-04:00

IPTC <<<
JFIF <<<
MakerNotes <<<
TimeZone : -05:00
TimeZoneCity : (not set)

XMP <<<
CreatorTool : DxO PhotoLab 5.1.3
DateTimeOriginal : 2022:03:30 21:52:22.889
MetadataDate : 2022:04:04 17:31:17-04:00
ModifyDate : 2022:04:04 17:31:17-04:00

From PL 5.2.0
File name: 20220330-215222_IMG_0766_dxo-1.jpg (ExifTool)

Composite <<<
SubSecCreateDate : 2022:03:30 21:52:22.89
SubSecDateTimeOriginal : 2022:03:31 01:52:22.889-00:00
SubSecModifyDate : 2022:06:07 09:51:10-04:00

EXIF <<<
CreateDate : 2022:03:30 21:52:22
DateTimeOriginal : 2022:03:31 01:52:22
ModifyDate : 2022:06:07 09:51:10
OffsetTime : -04:00
OffsetTimeOriginal : -00:00

File <<<
FileAccessDate : 2022:06:07 09:51:11-04:00
FileInodeChangeDate : 2022:06:07 09:51:10-04:00
FileModifyDate : 2022:06:07 09:51:10-04:00

JFIF <<<
MakerNotes <<<
TimeZone : -05:00
TimeZoneCity : (not set)

XMP <<<
CreateDate : 2022:03:30 21:52:22.89
CreatorTool : DxO PhotoLab 5.2.3
DateCreated : 2022:03:30 21:52:22.89
DateTimeOriginal : 2022:03:31 01:52:22.889-00:00
ExifVersion : 0230
MetadataDate : 2022:06:07 09:51:10-04:00
ModifyDate : 2022:06:07 09:51:10-04:00

As mentioned above with the Canon G5X the problem seems to be consistent. I also shoot with a Panasonic G9 that has the problem intermittently. I have not yet traced down the variable that causes the problem.

For example the raw file 2022-05-29-165818_P1079048.RW2 will always export with the date of export in place of the date taken.

While another recent file 2022-06-05-111722_P1079113.RW2 exports just fine with the original date in place.

I have place all referenced files here:

Please let me know if my explanation is not clear or if you need additional information or files.
Thank you,

Même problème pour moi! Cela détruit mon workflow.
Espérons que DxO corrige cela rapidement.

Je viens de faire un test avec PL3.

Fichier d’origine (CR2)…

Capture d’écran 2022-06-08 à 09.37.19

Exporté vers JPEG…

Capture d’écran 2022-06-08 à 09.38.38

Tout comme attendu.

Mais le problème que l’on voit c’est que PL5.2 n’écrit pas le tag exif:DateTimeOriginal dans le fichier exporté. du coup, la date est “traduit” d’un autre tag.

Voici toutes les dates dans un JPEG exporté avant PL5.2 (dans ce cas PL3)…

[File]          File Modification Date/Time     : 2022:06:08 09:58:25+02:00
[File]          File Access Date/Time           : 2022:06:08 10:00:46+02:00
[File]          File Inode Change Date/Time     : 2022:06:08 09:58:46+02:00

[EXIF]          Modify Date                     : 2010:12:11 13:25:51
[EXIF]          Date/Time Original              : 2010:12:11 13:25:51
[EXIF]          Create Date                     : 2010:12:11 13:25:51

[XMP]           Date Created                    : 2010:12:11
[XMP]           Create Date                     : 2010:12:11 13:25:51
[XMP]           Modify Date                     : 2010:12:11 13:25:51

[IPTC]          Date Created                    : 2010:12:11
[IPTC]          Digital Creation Date           : 2010:12:11

[Composite]     Date/Time Created               : 2010:12:11 13:25:51+01:00
[Composite]     Digital Creation Date/Time      : 2010:12:11 13:25:51+01:00

Mais, avec PL5.2…

[File]          File Modification Date/Time     : 2022:06:08 09:54:07+02:00
[File]          File Access Date/Time           : 2022:06:08 10:00:42+02:00
[File]          File Inode Change Date/Time     : 2022:06:08 09:57:43+02:00

[EXIF]          Modify Date                     : 2022:06:08 09:54:07
[EXIF]          Create Date                     : 2010:12:11 13:25:51

[XMP]           Create Date                     : 2010:12:11 13:25:51
[XMP]           Modify Date                     : 2022:06:08 09:54:07+02:00
[XMP]           Metadata Date                   : 2022:06:08 09:54:07+02:00

[Composite]     Modify Date                     : 2022:06:08 09:54:07+02:00

… on peut voir qu’il manque EXIF:Date/Time Original et c’est cette date qui s’affiche dans Finder.

Il s’agit bien sûr d’un bogue mais comme solution de contournement, on peut utiliser ExifTool pour corriger avec la commande…

exiftool "-exif:datetimeoriginal<xmp:createdate" nomDeFichier

@sgospodarenko could you signal this to the relevant person?

1 Like


Yes, sure. @kettch or @SebinParis could you, please have a look? :point_up_2:

Thank you
Svetlana G.

1 Like

Just to keep anyone watching up to date. I got an email request from Seth (Support & Assistance) requesting the dop files. Those have now been added to the same Google Drive folder.

He also requested unaltered files from the camera along with the dop file so I took a new photo from both of the cameras, opened them in PL to create the dop file and uploaded those also.

PhotoLab reads two dates from a raw file: Create Date (that we don’t modify) and Date/Time Original that we allow the user to alter using the Edit Shot Date panel.

When exporting, we export the Create Date if we got one from the raw, and we export the Date/Time Original if we got one from the raw or if the user added one using the Edit Shot Date panel.

In Photolab, we display the Date/Time Original if we have one, and the Create Date if not. I hope this clarifies.

Unfortunately, it might explain the theory but, in reality, it doesn’t explain why, when a RAW file contains a Date/Time Original, it no longer gets exported in PL5.2, whereas it used to in previous versions.

Please see the test data from my previous post.

I will check the changes made in 5.2 and get a fix done

Thank you. This problem is definitely a regression. Obviously somebody didn’t notice which tag gets used by Finder.

Could you please upload the CR2 image you used for your test (on ? I’ve tested also with a CR2 image, using PL 5.2 but the exported jpg does have the Date/Time Original tag.


File uploaded as requested.

ExifTool shows…

[EXIF]          Date/Time Original              : 2010:12:11 13:25:51
[EXIF]          Create Date                     : 2010:12:11 13:25:51

I’m using PL v5.2.3b56

My test export only checked EXIF metadata, because Date/Time Original is an EXIF tag. But, on testing it just now with all metadata instead of just EXIF, the exported JPEG now contains EXIF:Date/Time Original tag.

Taking things one step at a time, I found that, by including IPTC metadata in the export, I now get…

[Composite]     Date/Time Original              : 2010:12:11 13:25:51+01:00

… in the Composite section, which then shows the expected date in Finder.

Checking the docs, I find that Composite:DateTimeOriginal is a derived tag that is based on Composite:DateTimeCreated, which is, in turn, based on IPTC:DateTimeCreated.

So, if the user doesn’t want to export IPTC metadata, somehow, the EXIF:DateTimeOriginal tag gets overlooked.

One way to temporarily get around that bug is to set the APN time at UTC 0 and to set manually the current time. With this method, my original and exported files are correctly sorted by time in my (Capture One) catalog.

Hello @Joanna,

I exported with all checkboxes checked, but I don’t get the [Composite] Date/Time Original you mentioned. I only get [Composite] Date/Time Created, which is what the Finder displays in the Get Info panel as “Last opened”. I don’t understand why the Finder would display a creation date as a last opened date. Does it make sense to you ?

Ooops! My bad. I meant [Composite] Date/Time Created

When exporting for this test, with IPTC, I check the following options…

Capture d’écran 2022-06-13 à 10.25.07

This then gives me a file which, when viewed in Finder, gives me…

There is no problem when exporting with, at least, the IPTC tags included. The problem is when exporting with only the EXIF tags specified…

Capture d’écran 2022-06-13 à 10.30.46

… which then gives me the following…

Note the incorrect “Contenu créé” date.

This is not the case in earlier versions of PL, where that date is the same as if I had exported with the ITPC metadata.

To correct what I wrote earlier, Composite:DateTimeCreated is based on IPTC:DateTimeCreated and it is the latter which gets read and displayed as the “Contenu créé” value in Finder. But if IPTC:DateTimeCreated is not found, then Finder seems to default to one of the other tags, which relate to the exported file and not the original.

Thank you @Joanna, I will get this fixed. As several teams are concerned, it might not make it in the next release. I’ll keep you updated.

You mean the code for this needs changing in more than one place? :flushed:

Yes and no. I can make a change on my side to have the exif dates exported when the exif checkbox is checked (it is currently exported when the Attributes checkbox is checked). But we also want the IPTC date to be exported when the Exif checkbox is checked (and not with the IPTC checkbox). And this is under the control of another team. Plus the timezone from your image is currently not read, so a solution for that will also need a resolution. And we also want PL Windows to get these changes…

Looks like you need some kind of coordination between your teams… Moreover, I’m not sure if these tags are meant as information rather than a basis for calculations, and if they were, the calculations should be consistent imo…

1 Like

And I was thinking that an exporting algorithm would be in common code, since it’s only the checkbox or button that needs any difference in UI.

Mind you, I once acted as consultant on a multi-year rewrite of a business management package, rationalising the code as we went on. In examining the legacy code, we found there were about 500 customer-specific flags, which included or excluded certain code branches (total nightmare) and that the code for calculating VAT (sales tax) was written in seven different places, using slightly different code in each one. Sounds familiar? :roll_eyes:

On export to DNG

  • A fly poop (pink circle) next to the shot date as exported and shown by DPL:

  • Also, the correct lens info was destroyed in the export (pink rectangle) - and the statement about the colour profile has gone missing too…