Hi,
I never looked at this until now but I just noticed that the sidecar time in the DOP file is GMT+0, not the actual current time in France (GMT+1). For example
Sidecar = {
Date = “2020-10-28T13:53:13.6587827Z”,
while the file was actually created at 14:53:13.6587827Z.
Is this intentional ? My system date and time are OK as well as the modification time shown in Windows Explorer.
I program for macOS and iOS. We usually store all date/time data in “UTC” (0 offset), then it can be passed through the calendar on the users computer to show them their local time.
Don’t think it has anything to do with DPL at all, My world clock on iphone is reading Paris at Z and London at Z-1.
Which is correct. However, I was expecting the DOP file to be tagged with the local time. But maybe it’s intentional.
Shows what I know about world time. I thought London should be Z and Paris Z+1. Maybe some sort of DST glitch?
My mistake.
I had this problem when I wanted to recalculate a gps-tracker. Time is registered in what Johanna calls UTC and the timezone. Seems that dxo uses the UTC and timezone within it’s file but the file time is just the local time.
George
Hello guys,
Our developers have just confirmed - @Joanna is absolutely correct - this is exactly how it’s done for both platforms.
Regards,
Svetlana G.
Change your timezone and keep the local time. Force a .dop write and you’ll see another time.
George
It is the only way to keep one’s sanity! I am unsurprised that DxO are doing the same.
Let me explain why I was asking…
In Lightroom, the image thumbnail gets (if enabled) a small icon (up or down arrow) indicating which, between the database and the XMP file, is the most recent. This allows to decide whether the database information should overwrite the DOP file or reversely.
In DPL, this feature appears to be less relevant since the DOP files, unlike the XMP files, are less likely to be modified by another program. They could be modified manually, though. So, we can overwrite the DOP file with the database information or update the database with the contents of the DOP file but we do this blindly. We don’t know which is the most recent unless we look at the database with an SQLite tool and at the DOP file with a text editor/viewer. And what should we look at (see below) ? In the hope of a future enhancement of this feature (allowing us to be clearly informed before taking the decision), it’s important to be sure that the comparison is made on a safe basis (I’m referring here to a long lasting bug in Lightroom that sometimes creates an inconsistency between the time recorded in the database and the time stored in the XMP file).
Let’s look at what happens with DPL with an example. Let’s assume that I have disabled the automatic read/write options for DOP files in the preferences. For a particular file to which I have made a few changes, I have the following information :
Database (ModificationDate column in the Items table) : 2020-10-30 08:43:28.7519094Z
DOP file :
Sidecar = {
Date = “2020-10-30T08:30:58.7855001Z”,
Software = “DxO PhotoLab 4.0.1”,
Source = {
CafId = “C14383b”,
Items = {
{
Albums = “”,
CreationDate = “2013-05-20T09:21:20.6940069Z”,
ModificationDate = “2020-10-30T08:30:58.7821642Z”,
Name = “Ghost_Dancers_001.RAF”,
The DOP file shows different times which is correct since the automatic save option is not enabled.
After exporting to the DOP file a while later :
The database information was not modified since I didn’t make any change. So it’s still 2020-10-30 08:43:28.7519094Z
DOP file :
Sidecar = {
Date = “2020-10-30T09:00:15.9880299Z”,
Software = “DxO PhotoLab 4.0.1”,
Source = {
CafId = “C14383b”,
Items = {
{
Albums = “”,
CreationDate = “2013-05-20T09:21:20.6940069Z”,
ModificationDate = “2020-10-30T08:43:28.7519094Z”,
Name = “Ghost_Dancers_001.RAF”,
Then I re-enabled the automatic save/load settings to and from DOP file options and made a new change in the image after closing and re-launching DPL (if DPL is not re-launched, the results are inconsistent - it seems that the options are not immediately taken into account) :
Database (Modificationdate column in the Items table) : 2020-10-30 09:11:24.8243032Z
DOP file :
Sidecar = {
Date = “2020-10-30T09:11:24.8263011Z”,
Software = “DxO PhotoLab 4.0.1”,
Source = {
CafId = “C14383b”,
Items = {
{
Albums = “”,
CreationDate = “2013-05-20T09:21:20.6940069Z”,
ModificationDate = “2020-10-30T09:11:24.8243032Z”,
Name = “Ghost_Dancers_001.RAF”,
So, in any case, the ModificationDate in the database always matches the ModificationDate in the DOP file but it never matches the Sidecar Date (which itself matches the system last modification date with an offset depending on the time zone).
In automatic mode, the difference between the Sidecar Date and the ModificationDate might be very thin but it’s exactly why the Lightroom comparison procedure is buggy.
Well, everything appears to be logical. So, implementing a Lightroom-like feature indicating where the most recent modifications are stored should be easy to implement. This would make the DOP Export/Import operations safer.
Just a guess. A difference between the start of a modification, database, and the moment of writing the dop file, end of the modification.
Btw, how do you force a dop writing without editing?
George
ps
I did find it.
Manual read/write can be launched through the menu:
Good practice hint:
Before you quit PhotoLab, select all images and export the sidecars. This ensures that all you did in the customizing session is documented in the sidecar files - all except keywords 
Probably.
Interesting programming question, by the way : how to write in a file the exact writing time that will be recorded as the last modification time by the system ? Is this even possible ? I don’t think so.
Actually, this is not absolutely true. When looking at the DOP file last modification time (system) at the millisecond level, we can see that the Sidecar Date written in the file is a little bit earlier than the actual last modification time recorded by the system (I checked this with WMIC).
Not that important since I guess that implementing the above request would imply comparing the ModificationDate recorded in the database and the ModificationDate recorded in the DOP file. They always match at the millisecond level when the DOP file is manually exported.
