Date/time data being oddly modified on export?

DxO PhotoLab macOS topics
1

When uploading my photos to Flickr recently I’ve been noticing an odd behaviour. Shots from a single session were shown by Flickr as having been taken on two different days. I quickly ascertained that the problem occurs when I was shooting around noon. The photos have “shot” times 12 hours ahead of when they actually were. This happened for a couple of sessions and I just fixed them on Flickr.

Today I had a fresh session, all shot after noon, but thought I’d take a closer look throughout my publishing process. I discovered that PhotoLab is doing something odd with the times.

Here is what ExifTool shows me for “Time” tags for the original DNG file:

Date/Time Original              : 2022:04:25 14:03:42
Time                            : 14:03:42

Here’s what PhotoLab outputs in the JPEG:

Date/Time Original              : 2022:04:25 02:03:42
Offset Time                     : +12:00
Offset Time Original            : -00:00
Time                            : 14:03:42
Date/Time Original              : 2022:04:25 02:03:42-00:00
Date/Time Original              : 2022:04:25 02:03:42-00:00

I filtered the lists for Time so I assume the three that are the same are in different sections, but they are all the same, wrong, value. My time zone is UTC+12 so I get where that difference comes from, but why does PhotoLab rewrite the time like that?

3

Confirmed. PL5 is adding an EXIF data OffsetTime correction tag to the exports, and it is apparently basing that on the local time zone.

Why ???

1 Like
4

Until a fix can be issued for this, you might want to try exiftool to remove OffsetTime. I have never used OffsetTime in any images until it started appearing in PL5. (This is continuing frustration w/rt DxO about unannounced changes that lead to unintended consequences and unexpected workflow modification)

exiftool if you don’t know is a wonderful tool for examining and changing EXIF data. If you are unfamiliar with it, please do read up on it, and experiment with it before changing any client files.

The command

exiftool -offsettime= filename.jpg

seems to do the trick. The “=” sign has a blank after it; it will be equal to “nothing.” With this command, exiftool will create a second copy of the file without the offsettime EXIF tag, and will preserve the original under filename.jpg_original. There is a way to suppress that.

5

Maybe @sgospodarenko can help on this one.

6

Thanks. I used ExifTool to find the problem so am familiar with it. I’m already running an ExifTool command on the resulting images related to keywords, so I could just add this in as an extra step for now.

I’m not sure if just removing the Offset Time will achieve the right result though, as that will just leave the UTC time in Date/Time Original. That seems like it would force Flickr to assume UTC, but I don’t think that’s the case.

I do see that ExifTool could address this by adjusting it forward.

I probably won’t be shooting anything new for a bit, so will wait for now for someone on DxO staff to weigh in.

7

For completeness, the extra flag -overwrite_original will do what it says.

So I think it may be:
exiftool -offsettime= "-DateTimeOriginal+=0:0:0 12:0:0" -overwrite_original filename

That is untested however.

8

It may be a bit more complex than imagined. I used PL4 and PL5 to export the same image, saving each one, running exiftool on each, and then comparing the results.

Lines with “<” represent exiftool output from PL4
Lines with “>” represent exiftool output from PL5

< Creator Tool                    : DxO PhotoLab 4.3.3
< Date/Time Original              : 2021:12:24 07:22:40
< Date/Time Original              : 2021:12:24 07:22:40-05:00
---
> Creator Tool                    : DxO PhotoLab 5.2.0
> Date/Time Original              : 2021:12:24 12:22:40
> Date/Time Original              : 2021:12:24 12:22:40-00:00


> Metadata Date                   : 2022:04:25 19:51:51-04:00


< Modify Date                     : 2021:12:24 07:22:40
< Modify Date                     : 2021:12:24 07:22:40-05:00
---
> Modify Date                     : 2022:04:25 19:51:51
> Modify Date                     : 2022:04:25 19:51:51-04:00


< Offset Time                     : -05:00
< Offset Time Original            : -05:00
---
> Offset Time                     : -04:00
> Offset Time Original            : -00:00

In PL5, DateTimeOriginal is five hours advanced from what the photo really was (07:22 at 24 Dec 2021)

PL5 adds a metadata date, which is the current date/time.

ModifyDate is the original date/time in PL4; in PL5, it is the current date and time.

OffsetTime changes from -5h to -4h in PL5 (why?), and OffsetTimeOriginal goes form -5h to 0h. Again, why?

This behavior might be an outgrowth of DxO’s efforts to continue integration with other packages. DateTimeOriginal would be correct if assumed to be UTC, but is that how other applications interpret it? Clearly exiftool does not.

So there are a lot of puzzle pieces here. Maybe someone from engineering can contribute?

9

Yes that works. I omitted -offsettime and it also worked. Of course, readers in other locales are advised to substitute their UTC offset for the “12:” hours component. If you are Western Hemisphere you must use “-=” instead of “+=”. And then if you follow that up with

exiftool "-FileCreateDate<DateTimeOriginal" "-FileModifyDate<DateTimeOriginal" filename

then the OS file has the correct time stamp.

10

I just had a look at a tiff file, exported with DPL5 - no change in offset time etc… all goo.
This is on a Mac, Catalina

11

For me it only happens with images from mobile devices.

Again, I would like to stress this began recently, possibly with 5.2. It does not happen in PL4.

12

I can confirm the time shift in DPL 5.2.

13

That might be it. My test was on a tiff file, exported with 5.2 - and the raw file came from a Canon 40D