date problem - create date one hour off in some versions of files

[timoteo]

I am seeing quite a few files, raw and jpgs from the raw, that have capture time stamps that differ by one hour. It appears that imatch is somehow misinterpreting the time stamp on one of the two files.

In the attached screen capture, Windows file manager shows that the image was taken "12/11/2022 6:52 PM" (American date format - Dec 11,2022). The imatch thumbnail for the image shows the image capture date as   "12/11/2022 7:52 PM". 7:52pm instead of 6:52pm. 

The camera taking these photos was a Samsung S21+ phone (thought could be significant somehow).

The jpg file taken by the camera (name ending in "-M") was renamed in C1 using their "batch rename" command to rename to yyyy-mm-dd hh-mm-ss format using capture date as input. Adjustments were made in C1 to the original jpg file then exported as jpg with name ending in "-M-V" to the same directory. 

The original file shows the time of day the image was taken as 7:52pm. The exported version ("-M-V") shows the image was taken at 6:52pm. Since one file is derived from the other and I made no date/time changes, the two files should have the exact same capture time but do not.

This is confusing and screws up the sort on the page so that one image displays a few rows after the other, instead of side-by-side.  I have seen numerous others like this in my "Texas" directory too. 

[Mario]

Please provide a sample image that shows this problem.
Looking at some IMatch screen shots will not help.
Windows Explorer is not really a reference for metadata. Which time stamps does it use? EXIF? XMP? IPTC? Does it interpret and use time zone offsets in EXIF? Does C1?

IMatch processes date and time in your files as explained here: How IMatch uses Date and Time Information
It looks at time zone offsets in the file etc.

If you have processed a file with C1, there is a change that some metadata was changed.
Upload both of your test files to your cloud space and post as link.

Run the Metadata Analyst app in IMatch to check the metadata in both files.
C1 has caused problems with metadata in the past, maybe this is another case. Or it's a yet undiscovered bug in IMatch.
I can tell you more once I have seen the metadata in these two files.

[timoteo]

I followed the help link you provided for the metadata analysis tool but it does not tell me how to run it. Is it a menu item, a standalone program in the imatch directory, etc?

[thrinn]

I followed the help link you provided for the metadata analysis tool but it does not tell me how to run it. Is it a menu item, a standalone program in the imatch directory, etc?

It is one of the Apps delivered with IMatch. But you can also find it in the Tools menu:

[Mario]

In addition, searching for metadata analyst in the IMatch Help System produces The Metadata Analyst

And, remember to use the very handy IMatch Command Palette (Shift+Ctrl+P).
Just search for analyst and start it from there. Works for all IMatch apps, most features, commands etc.

[timoteo]

I don't have those options in imatch. I'm running imatch 2020 so I guess these are improvements you've made since them. I do have version 5 of Exif Pilot, though and it seems to be able to see all exif data so I think I should be able to look at the dates the images were taken and compare and post the results.

[timoteo]

I copied the two source files into an imatch folder in my dropbox account. I shared this folder with your supoprt email address. I haven't used dropbox in a long time so let me know if you have problems getting to these files.

I added a screen capture from Exit Pilot showing the metadata from imatch for both files. Both files show identical create dates. Create Date is identical for both files. The original file (sufix "-M") shows Date Subject Created is "3/6/2023 1:59:21 PM". The version exported from C1 ("-M-V") shows Date Subject Created as  "3/6/2023 1:59:21 PM-06:00".

Is this problem somehow related to Daylight Savings Time in the US?


 

[timoteo]

>>> Upload both of your test files to your cloud space and post as link.

I tried this but got an automated message from your support email address telling me not to do this. I have attached them to this post and the next post instead (it wouldn't let me attach them both to one post - together they use too much space).

[timoteo]

this post attaches the "-M-V" file referenced earlier. It was exported from C1.

What I see in imatch is that the thumbnail for this file shows the date/time to be 03/06/2023 2:59pm. The metadata information shown for this file in imatch shows Create Date "2023:03:06 13:59:21.414" and Date Subject Created "2023:03:06 13:59:21.414-06:00".

These two dates are one hour ahead of the date/time shown in the thumbnail.

[Mario]

I tried this but got an automated message from your support email address telling me not to do this. I have attached them to this post and the next post instead (it wouldn't let me attach them both to one post - together they use too much space).

There are no "automated" messages from my support address. It's always me and totally personal
I've just informed you that the DropBox link you sent was a private link, forcing me to create a DropBox account to download the files. Which I won't do, of course. A public link was all that's needed.

The images in your two posts have the same name and file size.
Are these the correct files? You mean a -M-V file name, but the file is named differently.
I also recommend ZIPping images before upload, to prevent accidental re-encoding by the community software.

I've looked at the "TX-2023-03-06 13.59.21-M.jpg" file and it shows this date and time information:

Code Select Expand

[ExifIFD]      Date/Time Original             : 2023:03:06 13:59:21
[ExifIFD]      Create Date                    : 2023:03:06 13:59:21
[ExifIFD]       Offset Time                   : -06:00
[ExifIFD]       Offset Time Original          : -06:00
IMatch shows these time stamps after import:

Code Select Expand

Create Date           2023:03:06 13:59:21.414-06:00
Date Subject Created  2023:03:06 13:59:21.414-06:00
which is correct. I need the "other" file to tell you more.

[timoteo]

I sent an email to your support email address just now; please delete it. 

Let me step back a bit. Maybe this is all based on an false assumption on my part.

After I search for file name "TX-2023-03-06 13.59.21" in imatch, I get two matches. Each image displayed in the results window shows the file name in white font in the top left corner. The line below it is the one I assumed (maybe incorrectly) is the date the picture was taken. This line is in bold yellow font. This is the part that doesn't match between the two files. The "-M" image shows this yellow field value as "03/06/2023 1:59 PM". The "-M-V" file shows this same value as "03/06/2023 2:59 PM". 

Maybe this second line is configurable and I've got it set incorrectly for what I want to see here. If it is configurable, I don't know how to configure it and you can explain or point me to the appropriate help section.

[Mario]

This depends on which File Window layout you have selected.
The Default File Window layout uses the Date and Time Original (Short Format) and this time stamp is derived from the UTC timestamp IMatch maintains for your files and the time zone offset recorded.
For your sample image, I see



and when I change the File Window layout to also display the time zone offset, I get



which matches the time stamp found in the File, the global File.DateTime value IMatch maintains for each file.
See How IMatch uses Date and Time Information for all details.

If you see a different time stamp for your other file, check the date subject created in the metadata panel. I'm quite sure that the either the time is really different or there is a different time zone offset recorded in the file.

Keep in mind that IMatch considers the daylight saving time (based on the date of the file) and your local time zone.

Without having the other file, I can make only assumptions. But I would just check the date subject created and maybe run the ExifTool Command Processor with the "List Metadata" preset to see the actual date and time recorded in the file.

[Mario]

Thanks for sending in the two sample files.
I see the following metadata in the files:

TX-2023-03-06 13.59.21-M.jpg (Original)

Code Select Expand

[ExifIFD]      Date/Time Original             : 2023:03:06 13:59:21
[ExifIFD]      Create Date                    : 2023:03:06 13:59:21
[ExifIFD]      Offset Time                    : -06:00
[ExifIFD]      Offset Time Original           : -06:00
IMatch correctly shows the date and time as

Code Select Expand

Create Date          2023:03:06 13:59:21.414-06:00
Date Subject Created 2023:03:06 13:59:21.414-06:00

For the second file TX-2023-03-06 13.59.21-M-V.jpg (Metadata written by Capture One 22 Windows) I see:

Code Select Expand

[ExifIFD]      Date/Time Original      : 2023:03:06 13:59:21
[ExifIFD]      Create Date             : 2023:03:06 13:59:21
[IPTC]          Date Created           : 2023:03:06
[IPTC]          Digital Creation Date  : 2023:03:06
[XMP-xmp]      Create Date             : 2023:03:06 13:59:21.414
[XMP-photoshop] Date Created           : 2023:03:06 13:59:21.414


The EXIF time zone offset of -06:00 has been stripped from the file and is not present in the XMP time or legacy IPTC metadata.

Why C1 has created legacy IPTC data is unknown.
Why C1 has removed the time zone offset from EXIF is unknown.
Why C1 has not applied the EXIF time zone offset to the XMP unknown.
Why C1 has not written the EXIF time zone offset to the IPTC time zone offsets is unknown.

IMatch shows the following time stamps for this file:

Code Select Expand

Create Date          2023:03:06 13:59:21+02:00
Date Subject Created 2023:03:06 13:59:21+02:00
The time zone offset is added based on the time zone offset on my computer, which is currently at +02:00.
Since the metadata in the second file has no EXIF or XMP or legacy IPTC time zone offsets anymore, this is how IMatch should deal with this.

[timoteo]

Thanks for your hard work in figuring this out, Mario!

I have had many problems with C1 over the years so i guess i shouldn't be surprised that C1 screwed this up.