Renamer not picking up correct date and time.

[gheppell]

I am tring to rename some of my picture files from a recent trip that was in the -08:00 time zone.  Per the attached screenshots everything is fine except when I want to rename.  The renamer adds an hour to the time.  I have used timewiz to reset the time, erased all metadata then manually entered the time but nothing works, renamer insists upon adding an hour.  For the first hour that I was working on files today it worked fine, then poof, the issue started and nothing I do seems to resolve it.

thanks

[gheppell]

Here is the actual file for you to test with.  thanks

[Mario]

Which steps do you use in the Renamer?
The Renamer uses the global File DateTime (What Is File.DateTime?) in your local time zone. You can see it e.g. in the VarToy using {File.DateTime}. If you need more control over if and how time zones are applied, you can use a Text & Variables step instead, for example with these variables:

Code Select Expand

DT: {File.DateTime}
DT: {File.DateTime.TZO}
UTC: {File.DateTime.UTC}
LT: {File.DateTime.Local}
LT: {File.DateTime.Local.TZO}
Org: {File.DateTime.Original}
Org: {File.DateTime.Original.TZO}

When I use the default HH-MM-SS step, I get this file name:

18-55-45.JPG

which matches the time stamp of the file in my local time zone (+01:00). The above variables return these values for your image on my computer (in your time zone they will be different):

Code Select Expand

DT: 23.11.2024 09:55:45
DT: 23.11.2024 09:55:45-08:00
UTC: 23.11.2024 17:55:45
LT: 23.11.2024 18:55:45
LT: 23.11.2024 18:55:45+01:00
Org: 23.11.2024 09:55:45
Org: 23.11.2024 09:55:45-08:00
The Renamer formats date and time in the local time zone, which works well for the majority of users. If you want to access a specific time or format date or time in a specific way, use a Text & Variable step. This gives you access to the global datetime, the date and time in UTC, your local time zone and the original date and time found in the image.

For example, this variable in a Text & Variables step

{File.DateTime.Original|format:YYYYMMDD_hhmmss}

produces the file name

20241123_095545.JPG

[gheppell]

thank you.  This did work but I am still confused.  I have named literally thousands of these in iMatch after changing or adding a time zone different from my own using TimeWiz, and they all renamed to the time the photo was taken, in the time zone it was taken, not my local time zone.  Perhaps I inadvertently changed a Preference/Setting?

[gheppell]

After testing your solution here is my output.  Once the file updates the timezone on the date.time.original changes to my local time zone (-07:00).  As you can see I used TimeWiz to change CreateDate and DateSubject Created to the time zone in which the picture was taken (-08:00).  Hmmmmm?

[gheppell]

[Mario]

IMatch only works with "Date Subject Created" and "Create Date" (the two first timestamps in your screen shot). File.DateTime is derived from "Date Subject Created".

The "XMP::photoshop\DateCreated\DateCreated" tag (Date Subject Created) is linked to it's XMP EXIF counterpart "XMP::exif\DateTimeOriginal\DateTimeOriginal" and when the contents of "Date Subject Created" are modified, the EXIF::exif tag should (Date/Time Original) update accordingly.

When I change "Date Subject Created" directly in the MD Panel, or via TimeWiz, "Date/Time Original" is updated to the same value. What exactly do you do in TimeWiz, what's your local time zone etc?

[gheppell]

The video shows exactly my process.  I think the issue is related to the Exif:Main:OffsetTime tag.  When I search it up it is supposed to be a tag related to the modify date.  It makes sense that it resets to my computer's time zone each time I make a modification.  However, it looks as though Date/Time Original is inheriting the offsettime time zone after a modification.  

[Mario]

I did not watch the video. YouTube cookies, YT collecting my IP and all that.

There are 3 Time Zone Offset in EXIF metadata. One for "Date Subject Created", one for "Create Date" and one for modify date. IMatch does not manipulate any of them directly. When you write-back (I assume this is what you mean by "change") ExifTool sets the Modifed timestamp in the file and also the time zone tag. This is supposed in local time, I believe, by the XMP and EXIF specs.
It also sets the two other EXIF offsets from the "Date Subject Created" and "Create Date" when IMatch writes them.
When I write back the file in my screen shot, nothing changes with the timestamps, as expected. The XMP timestamp is set as

[XMP-xmp]      Modify Date                    : 2025:01:13 19:13:40+01:00

which is my local time and time zone. This is how it should be.

I don't see how the EXIF modified date (or it's XMP counterpart) should impact the time zone of "Date Subject Created" or "Date Created". When looking for time zone offsets in EXIF during import (if the file has not XMP data already), IMatch only looks at the EXIF offsets for "Date Subject Created" and "Create Date". It does not use or care for the "Modified" Offset.

But, metadata is messy.

I'm maxed out 2 times with my work-load currently, but if you have an image file and a workflow that produces this behavior, I can have a look when a time slide becomes available.

[gheppell]

Here is the process that created the error:

1.  In TimeWiz I set the time zone for where the picture was taken (-08:00 in my case).  I do this for 'Date Created and Date Subject Created.  After I write this back, Date/Time Original inherits this time zone as I would expect and want it to.

2.  Then I make a modification like reverse geocoding as one example.  I then write back this change.  Of course, modiy date inherits the time zone of my computer (-07:00 in my case).  Date Created and Date Subject Created are not altered.  HOWEVER, Date/Time Original inherits the time zone of my computer.  It changes from -08:00 to -07:00 when I write back the info from reverse geocoding (or any other modification).   

The two screenshots below provide more detail.  The only thing that I have done between the first and second photo is reverse geocode.  The exact same thing happens with other modifications as well (rename for example.)

thank you

[Mario]

The only thing that I have done between the first and second photo is reverse geocode.

Reverse geocode does not write-back or modify time stamps (sans GPS timestamps). Or did you also write-back?
In which case ExifTool modifies timestamps. You can see what IMatch is sending to ExifTool in the output panel when you write back. Anything unusual?

As I said, need sample image before I can even start.

Please allow for a couple of weeks until I have time to look into this. One user with yet another obscure metadata problem. Since no other user has reported something similar (or nobody is looking at or using original date and time), this might be something that happens only with the specific existing metadata in your files, e.g. a mismatch in tz offsets in native EXIF and what ExifTool makes about it. Who knows?

[PandDLong]

The video shows exactly my process.  I think the issue is related to the Exif:Main:OffsetTime tag.  When I search it up it is supposed to be a tag related to the modify date.  It makes sense that it resets to my computer's time zone each time I make a modification.  However, it looks as though Date/Time Original is inheriting the offsettime time zone after a modification. 

I had a similar issue a few weeks ago.  I decided to not use Date/Time Original as it seemed to be the one that was getting messed up and I switched to just consistently using the DateSubjectCreated tag.
(As a side note, I am finding those Composite tags are increasingly error-prone as the logic in ExifTool attempts to rationalize other tags and as metadata can be messy that logic is not always representing what is intended - IMO).

In the process of trying to solve this issue, I did look at the ExifTool Output panel and decided that it appeared to be an Exiftool problem - as the data seemed to be sent to it correctly but then it came back with that offset tag reset.  However, my ability to interpret this panel is only so-so.

I will attempt to recreate this situation as it may help Mario track it down for that future date when he has time to look at it.  If I can't recreate it, I will post that also.

Michael

[Mario]

(As a side note, I am finding those Composite tags are increasingly error-prone as the logic in ExifTool attempts to rationalize other tags and as metadata can be messy that logic is not always representing what is intended - IMO).

Composite tags are made up by ExifTool from a wide variety or sources. They should not be used generally.

[Mario]

I've had a wee look at this and figured out these steps to reproduce:

Change the time zone of "Create Date" and "Date Subject Created" e.g. to -11:00
This updates

XMP::xmp\CreateDate\CreateDate
XMP::photoshop\DateCreated\DateCreated
XMP::exif\DateTimeOriginal\DateTimeOriginal

with the new -11:00 offset ( DateTimeOriginal  is linked with photoshop\DateCreated).
Write back.
All dates are written correctly and reloading the file shows the time stamps all with the -11:00 offset.
The native EXIF data is updated and now also uses the -11:00 offset:

[ExifIFD]      Offset Time Original            : -11:00
[ExifIFD]      Offset Time Digitized          : -11:00

Now make any change to the file, e.g. set a rating and write back again.

IMatch does not send any time stamp changes to ExifTool, only the rating update.
But what I see in verbose output of ExifTool is this:

Code Select Expand

- XMP-exif:DateTimeOriginal = '2024-11-23T06:55:45-11:00'
+ XMP-exif:DateTimeOriginal = '2024-11-23T06:55:45'
ExifTool removes the existing DateTimeOriginal  (with the correct tzo) and replaces it with a timestamp without a time zone!
I have no idea why it does that.

I can only post this as a question in the ExifTool community to learn more about this behavior and why this happens and how I can prevent it.

[axel.hennig]

Because I was interested, I tried to reproduce this (and was able to do).

I've used the image from above ("Nov 23, 2024@09.55.45.JPG") to make this test.

From Mario's post on how to reproduce this there are three different Metadata-states

• Metadata when file was imported into IMatch
• Metadata after using TimeWiz to change "Date Created and Date Subject Created" and write-back
• Metadata after setting Rating and write-back

My observation which I found also interesting was:

Metadata (at state 1):
[IFD0]          Software                        : photools.com IMatch 23.14.0.1 (Windows)
[XMP-tiff]      Software                        : photools.com IMatch 23.14.0.1 (Windows)
[XMP-xmp]       Creator Tool                    : photools.com IMatch 23.14.0.1 (Windows)

Metadata (at state 2):
[IFD0]          Software                        : photools.com IMatch 23.14.0.2 (Windows)
[XMP-tiff]      Software                        : photools.com IMatch 23.14.0.1 (Windows)
[XMP-xmp]       Creator Tool                    : photools.com IMatch 23.14.0.2 (Windows)

Metadata (at state 3):
[IFD0]          Software                        : photools.com IMatch 23.14.0.2 (Windows)
[XMP-tiff]      Software                        : photools.com IMatch 23.14.0.2 (Windows)
[XMP-xmp]       Creator Tool                    : photools.com IMatch 23.14.0.2 (Windows)

[axel.hennig]

I can only post this as a question in the ExifTool community to learn more about this behavior and why this happens and how I can prevent it.

Phil already provided an answer. He states that with the next update of ExifTool the problem should be gone, but not sure about my first post.

[Mario]

Phil already provided an answer. He states that with the next update of ExifTool the problem should be gone, but not sure about my first post.

I've read his post and replied already.
The difference in version numbers could be the fact that the metadata initially was written with a trial version of IMatch (odd version number).

[axel.hennig]

The difference in version numbers could be the fact that the metadata initially was written with a trial version of IMatch (odd version number).

Yes, but why does my first write-back produce endings in version numbers 2-1-2 and my second write-back 2-2-2?

[Mario]

Can you open a separate bug report?
I don't want to mix a OriginalDateTime tag losing it's time zone with a wrong version number in a totally unrelated tag.

When I recall correctly, some tags are only to be set once, by the first software used. IMatch checks for XMP::Creator and only sets it when empty or it is already photools.com IMatch (Windows) but maybe with a different version number. IMatch only writes XMP::xmp::CreatorTool, the other tags are filled by ExifTool mappings.

Maybe the effect you see is caused by ExifTool mapping between different tags during write-back. Updating an existing photools.com entry is OK

[Tveloso]

Could it be that IMatch/ExifTool didn't actually touch anything in the [XMP-tiff] group during that first WriteBack?...(so the version stayed at ".1")?

[Mario]

IMatch only ever writes XMP::Creator, the mapping to the XMP::TIFF tag and the native EXIF tag in IFD0 is done by ExifTool during the mapping process. And IMatch writes to XMP::Creator only when it is empty or when it contains a previous photools.com IMatch entry. I don't think this mapping issue is worth any further analysis.