[NR] Date Original and Time Original failed to get updated (by Timewiz?)

[ubacher]

I corrected the time in files where I had forgotten to set daylight savings time on the camera. (Added an hour using Timewiz, Ver. 2023.1.4 )

By many files, a few in a row usually, the Time displayed in the file window layout which uses
Date Original and Time Original was not changed. Randomly it failed to update.
First I figured out to fix this by adding to all files one second and then removing a second. This caused
Date Original to be updated OK.

Now I changed the file window layouts to use Date Local and Time Local which did seem to be updated OK.

This of course means I won't see in future if this will happen again.

Note that the files affected were all taken in sequence by the same camera. NEF and corresponding jpg files
were equally affected.

[Mario]

I have to admit I cannot really follow your post.

The global File.DateTime is produced from XMP Date Subject Created.
Date & Time Original (I assume you mean the File Window attribute of that name?) is straight from the metadata of your file.

If you change "create date" or "date subject created" in the TimWiz this updates the database. You need to write back so ExifTool maps these time stamps to their corresponding EXIF time stamps again. This updates the original date and time, which source the Date & Time Original time stamps.

Date Local sources from the global File.DateTime and is calculated from UTC and your local time zone.

See How IMatch uses Date and Time Information

I need more details, screen shots, sample file time stamps from the Metadata Panel and details about the layout you have created to answer this. I have tried to make it very clear how all this relates in the help topic linked above. An image file can have up to 15 different time stamps, but only two are relevant for IMatch (and updated by the TimeWiz and then promoted back to their EXIF counterparts during write-back, which then again updates their linked XMP time stamps on re-ingest).

Most users will only ever need the default File.DateTime which is shown in your local time zone by default and for backwards compatibility - by the File Window layout Attribute and the corresponding variable.

[ubacher]

Date & Time Original (I assume you mean the File Window attribute of that name?) is straight from the metadata of your file.

But Time Original did not get updated. (On some files in a series of files) All other times were correct.
I noticed this because this is what is displayed on the thumbnail layout in the file window panel.

It looks to me like these updates where done in junks, by different sub processes (maybe in parallel?), and some did not finish correctly (i.e. before updating the Time Original)

[Mario]

But Time Original did not get updated.

Time Wiz does not update this time stamp. It updates

a) XMP::photoshop\DateCreated\DateCreated (Date Subject Created)
b) XMP::xmp\CreateDate\CreateDate (Create Date)

The global File.DateTime is updated when a) changes.

The UTC / Original / Local time stamps you can display in the File Window (or via the corresponding variables) are all created dynamically (calculated) from the global File.DateTime.

Do you say that the TimeWiz fails to sometimes update these two tags?
Or do you mean something else?

Which tag or variable or File Window attribute do you mean by "Time Original"?
Show me the tag key (copy as variable command in the context menu of the MD panel) or the File Window layout used or the variable ...

[ubacher]

Thumbnail editor:

[Mario]

This File Window layout attribute is calculated from the global File.DateTime value IMatch maintains for each of your file.
For images, File.DateTime is set from Date Subject Created (XMP::photoshop\DateCreated\DateCreated) and this time stamp is updated by TimeWiz.

Did you verify that TimeWiz indeed has failed to update the Date Subject created for some of your files?
Which type of file and under which conditions does this happen?
There should be a warning logged to the log file and the TimeWiz should reports the problem when it gets an error back from IMWS while modifying metadata.

Every detail matters, as usual, e.g. how many files did you process, which operations did you perform in the TimeWiz etc.
If we can find steps to which allow me to reproduce this problem, I can fix it.

[ubacher]

Will have to wait till next time it happens. Difficult to detect when it does happen.

[Mario]

OK.
I'll close this ticket.
Open a new one when you have a hint about what may cause this.