Wired. When I export a RAF (Fuji) file from LR to PL and export it back either as DNG or JPG, it adds three hours to the timestamp… so a photo shot at 13:47h shows as been shot as 16:47h… can’t figure it out… Any ideas?
…probably a simple bug in DPL’s metadata handling. The effect has also been reported in other posts. I suppose that DxO is already working to fix the issue…
Probably the difference between universal time and local time.
George
Yeah, I have this issue. Being 12 hours ahead of UTC makes it all the more confusing, as often the time I see “seems right”!
I do confirm this issue with 2 hours difference in France…
That definitely sounds like the difference between UTC and French summertime.
In my opinion, this should not be happening.
2 Likes
Think so, too. Is it a new “feature”? Maybe in combination with support for GPS data?
Fully Agree
for comparison (Win)
checked w/ Panasonic DMC-LX100 & Nikon D750
[ in-camera time zone = GMT+1 ( → summertime in CEST / Madrid, Paris, Berlin ) ]
RAW - file
ExifTool
// 
// 
PL5.2.1_4737 PhotoLibrary (Win)
// 
// 
PL5.2.1_4737 Customize (Win)
modified RAW - file & exported as JPEG
// 
// 
I detailed this behavior about a month back in another post, and it’s really confusing because there are multiple factors at play: at the least, TZ when shot was made, TZ when exported, TZ diff between image creation and export, device used, possibly DST on or off.
The problem is in the EXIF data on the export, specifically the dateTimeOriginal tag and possibly others.
An image I made on a Nikon while in CEST (UTC+2):
- Shot - 09:32:47
- Exported - 15:32:47 (as reported by dateTimeOriginal)
- Diff: +6h
An image I made on a mobile a few minutes earlier in CEST:
- Shot - 09:30.33
- Exported - 13:30:33
- Diff: +4h
An image I made on a Nikon while in US EDT (UTC-5):
- Shot - 13:57:33
- Exported - 13:57:33
- Diff: 0
But earlier that same day, another image made on a mobile:
- Shot - 12:52:13
- Exported - 16:52:13
- Diff: +4h
I don’t know if these data points are enough to help identify and repair the problem, but IMHO PL5 should NEVER be trying to interpret and change these EXIF fields. Mobile devices already have tight synchronization with external clock sources, and DSLR owners (this owner anyway) is careful to watch the time on the body.
What is really frustrating though is that this is a self-inflicted wound on the part of DxO and PL5. This was never a problem before and suddenly showed up when my workflow was producing unexpected results. I don’t know what feature this code change was designed to support, but it’s clearly wrong.
1 Like
I hope someone at DXO is reading all of this…
To be more sure of that, I suggest tagging your original post as a bug or report it to support.dxo.com.
1 Like
Fyi… still a bug in DxO 7 so I guess someone at DxO is NOT reading these posts.
Has anyone reported it as a bug through support.dxo.com? That’s the right place to report bugs. Here we can only talk about them, unless someone at DxO asks us to post info here. No one even tagged this discussion thread as a bug.