[BBD] Sort Glitch - Capture Time

[jch2103]

I noticed today that I'm getting a glitch with sorting by Capture Time. The attached screenshot shows the problem. Two images (in the DSC_6674 series) are sorting following several shots taken at later times. A look at metadata for the whole DSC_6674 series shows all these images displaying the exact date/time values using the '1 Default' metadata view (date/time is visible in the thumbnails). The problem seems to be confined to this particular folder. Rescanning the folder, running IM diagnostics, etc., hasn't resolved the issue. 

Any suggestions on how to fix this?

[axel.hennig]

Can you please also show the time-zone offset. Maybe something happened there.

Edit: Can you please also show which Metadata/Variable you are using to show the date/time (in your screenshot) -> shoud be File.DateTime (I guess to match how IMatch is sorting internally)

[jch2103]

All the DSC_6674 series images have the same date/time: 2023:10:10 08:20:21.08-06:00
The '1 Default" metadata layout shown in the screenshot uses {File.MD.XMP::xmp\CreateDate\CreateDate\0} and {File.MD.XMP::photoshop\DateCreated\DateCreated\0}. So does my default metadata layout. 

({File.MD.XMP::xmp\ModifyDate\ModifyDate\0} has different values between images, based on when they were last generated/modified, of course, but that shouldn't affect the sort order especially compared with other images taken at different times.)

[Mario]

The default Capture Time sort profile sorts by

Capture Time (the global File.DateTime value) and then by Smart File Name (Smart).

The File.DateTime is based on DateSubjectCreated, not on Createdate or ModifyDate. If you want to sort by these tags, just create your own sort profile.

Which time stamp do you show in the File Window?
When you look at the "Date Subject Created" for the files in question in the Metadata Panel, is the correct date and time shown?

[axel.hennig]

Hm, interesting. Can you upload (zipped that Metadata is kept) the following three files:

• DSC_6674_DxO AP2 4K.jpg
• DSC_6676_DxO.jpg
• DSC_6674_DxO.jpg

I will try to reproduce your problem.

If you don't want to share of course no problem, but it might get difficult to reproduce your problem.

[jch2103]

Thanks! Here's a link to the three images: https://1drv.ms/u/s!AtlBwiIf8wQzgZt6oNNezOFnO2Jgmg?e=Ick9PN

The File.DateTime is based on DateSubjectCreated, not on Createdate or ModifyDate. If you want to sort by these tags, just create your own sort profile.

Which time stamp do you show in the File Window?
When you look at the "Date Subject Created" for the files in question in the Metadata Panel, is the correct date and time shown?

I see what happened. My custom file window used 'Time & Date Original (Short Format)'. If I switch to 'Time & Date Original (Short Format) with time zone offset', the file window date/time TZ shows the two 'odd' files as being -07:00, although my metadata panel (using {File.MD.XMP::xmp\CreateDate\CreateDate\0} and {File.MD.XMP::photoshop\DateCreated\DateCreated\0}) shows TZ as -06:00. 

What I don't know is why the TZ ' Date & Time Original' got changed to -07:00 from the original -06:00. I had created both images from the original NEF using PhotoLab 7. I need to re-read the Help section you referenced and check the date/time outputs in JPGs from PhotoLab 7 to better understand what's going on and prevent this in the future. 

(If I recall correctly, the JPG output file from PL7 leaves out the TZ from the {File.MD.XMP::photoshop\DateCreated\DateCreated\0} tag; I had edited the tag to include the proper -06:00 TZ. But that doesn't explain why the 'Date & Time Original' for the output file is being recorded as -07:00.)

[Mario]

See UTC and Local Time for related information.
Check the time stamps and time zone offsets in the images in questions using the ExifTool Command Processor (search for date and search for offset).

When IMatch transforms from UTC into local time using the time zone offset determined on ingest, it uses a time zone database (actually, the Windows routines IMatch uses do) to determine the DST from the date, assuming your local time zone. 
IMatch currently does not use country data or performs GPS-based lookups to determine the DST at the date and location the file was taken. This appears to be overkill for the vast majority of IMatch users.

[axel.hennig]

I think the problem is:

Tag: [XMP-exif] Date/Time Original

• DSC_6676_DxO.jpg: 2023:10:10 08:37:14
• DSC_6674_DxO.jpg: 2023:10:10 08:20:21
• DSC_6674_DxO AP2 4K.jpg: 2023:10:10 08:20:21-06:00

That means the "...4K.jpg" file does hava a TimeZone and the other two files not (in that specific tag). That's why on my system (Germany; currently +01:00) IMatch wants to write +01:00 to the other two files (based on my TimeZone settings). And that's why it seemed sorted wrong, but it is actually correct (different TimeZones).

Did you shoot the images at -06:00 and now you are currently at -07:00?

What I also see in the Metadata is:
[Nikon]        Daylight Savings                : Yes
Could this cause a problem?

[jch2103]

Thanks. I think I now understand and have fixed the issue for now. I have a bug report in to DxO about a missing time zone in one of their JPG output file tags (it's OK in most of the tags). (The missing TZ caused IMatch to use the current -07:00 time zone where I am (-07:00) for images processed recently instead of the -06:00 time zone when the photo was taken.) 

I've been able to fix the images I identified above by assigning a time zone via the Time Wiz app and then doing a force rescan of these files. The force rescan was necessary to get IM to override the File.DateTime, which Mario points out is based on DateSubjectCreated (which defaulted to -07:00 for the recent files with missing TZ). Mario - What is the full name of this tag? I didn't find it when trying to further customize my metadata template. 

Mario - You should be able to mark this one closed. Thank you Mario and @axel.henning for your insights. 

[Mario]

A rescan is usually not needed since the TimeWiz directly updates the time stamps in your database.

IMatch shows the tag key when you point at the header column in the MD panel.



(Don't mind the oid part, that's only available for me).

And you can right-click into the header and use Copy as variable to get the tag key to use as a variable or, after removing the File.MD. and the {} as a tag key.

See Additional Commands and Options

[sinus]

Thanks for clarificaton about the variable, with what File.DateTime is based.

I was a bit shocked about this sentence "The File.DateTime is based on DateSubjectCreated, not on Createdate or ModifyDate. " and thought, what the heck is this?

Because I based all my date/time - stuff on th the variable  {File.MD.XMP::photoshop\DateCreated\DateCreated\0} and when I read your last post, this is correct. Phew. 

Good, all is fine again and John could also solve his problem. 

[Mario]

Date subject created is usually identical to create date, unless the user modifies the time stamps.
According to the IPTC and XMP, the date subject created is to be preferred because it defines the time the photo/image was created, and not the create date of the digital image file.

Digital cameras set both time stamps to the same value, obviously.
But when you digitize a film photo, and the original slide shows a photo taken on 1970/1/1, the create date will be the date and time the scan was created and the date subject created should be 1970/1/1.