Advice Please On Time and Date Issues

[J.D. McDowell]

I have a problem with some coruption that has crept into some of my NEF files. I'm certain that this was caused by the combination of an earlier beta and my attempts to get iMatch running under parallels on a mac (I know, I know, some people just like taking the hard road.)

I any event, everything works great now, but I have hundreds of files with time and date issues.  One example is shown below; the custom panel shows date and time info in the following order

{File.MD.Exif::Main\36867\DateTimeOriginal\0}
{File.MD.Exif::Main\36868\CreateDate\0}
{File.MD.Microsoft::XMP\DateAcquired\DateAcquired\0}
{File.MD.XMP::exif\DateTimeDigitized\DateTimeDigitized\0}
{File.MD.XMP::exif\DateTimeOriginal\DateTimeOriginal\0}
{File.MD.XMP::exif\GPSTimeStamp\GPSDateTime\0}
{File.MD.XMP::photoshop\DateCreated\DateCreated\0}
{File.MD.XMP::xmp\CreateDate\CreateDate\0}

Some files with these or similar errors (some files show 12am and an incorrect date in most fields, some just the incorrect time, the time 12am is the only common factor) have GPS data, most do not.

You can see in this case that "Date Subject Created" {File.MD.XMP::photoshop\DateCreated\DateCreated\0} is incorrect. Selecting the field to edit it shows there is actually only date info, no time info, in the field. I'm guessing the 12am is simply a place holder when the data is absent. Also, the time zone data in "Create Date" {File.MD.XMP::xmp\CreateDate\CreateDate\0} stated as -4:00 is wrong. The time zone is Eastern North America, which is -5:00. The times however do properly reflect the correct offset against the GPS time (the 5 hour difference.)

The advice I'm looking for is on a way to fix these files. There are 202 files with this particular error, there are more elsewhere in the database. I have corrected a bunch by cutting and pasting the correct data into the appropriate fields, but I'll spend days doing this at this rate.

Is there a way to force iMatch to "redo" the date and time info from the original exif data? (Ctrl+Shift+F5 didn't work.)

Is this something that could be accomplished with a script, or the ECP?

Is there a way to query the time stamps to find all files with a 12am time stamp in any field?

Any advice on how to approach this problem will be greatly appreciated.

[attachment deleted by admin]

[Mario]

Is there a way to force iMatch to "redo" the date and time info from the original exif data? (Ctrl+Shift+F5 didn't work.)

This re-imports the metadata from the file, mapping IPTC/EXIF/GPS data into XMP. If the EXIF timestamp would be correct, this would fix the XMP on import (and write-back). If you fix the XMP Digitized/Orignal date and time in IMatch and write-back, IMatch will update the EXIF timestamps in the file as well.

If the GPS timestamps are "more right", you can copy them to the EXIF timestamps with ExifTool or the ECP. Would that be an option? IMatch will on re-import import the then fixed EXIF timestamps into XMP as well.

Is there a way to query the time stamps to find all files with a 12am time stamp in any field?

This would be 12:00:00. You could use the search bar, the metadata search or even create a data-driven category on the tag, with a filter on 12:00:00... Many options. I did not try this but I'm sure at least one will work.

[J.D. McDowell]

Still having odd issues.

Went back to my Windows machine (just to eliminate other potential problems) and opened a bad file.

I used the modify Exif Date and Time tool to do this. I used "Use system time zone" yet the output was still incorrect (please see the screen shot.)

The system time zone is -5:00, yet the output was once again -4:00.

Please note the metadata panel is showing the output after using the modify Exif Date and Time tool.

[attachment deleted by admin]

[Mario]

Check the output in the ExifTool Output panel.
Please attach log file, because it contains the time zone offset for your machine, including daylight saving time!

[jch2103]

I used the modify Exif Date and Time tool to do this. I used "Use system time zone" yet the output was still incorrect (please see the screen shot.)

The system time zone is -5:00, yet the output was once again -4:00.

Yes, but...! My system Date and Time adjustment shows the same thing, but check what your settings are for 'Change time zone'. Mine has the check mark clicked for 'Automatically adjust clock for Daylight Savings Time'. See attached.



[attachment deleted by admin]

[J.D. McDowell]

Yup, I just tried this, the issue is because DST is enabled. So technically, mathematically, it is generating the correct UTC and other fields based on that, but that's not the normal convention on how to read those time stamps in human form.

My problem then is that for the given location of the shot the "time zone" then reads incorrectly.

{File.MD.XMP::exif\DateTimeDigitized\DateTimeDigitized\0} is still not updating when using "Force Update" for a rescan. "Protect unwritten metadata" and "Keep existing XMP" are both set to "No" in the Metadata 2 preference dialogue.

Below is the metadata written with the same settings in the modify Exif Date and Time tool as before with DST turned off manually on the machine.

[attachment deleted by admin]

[jch2103]

My problem then is that for the given location of the shot the "time zone" then reads incorrectly.

I'm not sure there's a fully satisfactory date/time display solution for all users and all situations. This is a pretty convoluted subject (especially with the complications of DST) and has been discussed extensively on the forum a number of times, e.g., https://www.photools.com/community/index.php?topic=1679.0

Mario made changes in time/date display several versions ago to include time zone (which didn't previously display for tags that can contain it). I think that's an improvement over the earlier behavior, but maybe there's a different, better way that hasn't been suggested yet.

[Mario]

I'm not sure what solution you suggest.
DST is always a problem, whether you use it or ignore it.

If IMatch asks Windows for the time, Windows will adjust for DST. That's the system time zone.
Maybe just set the time manually to whatever you like?

[J.D. McDowell]

Sorry to keep rehashing this, I've been thinking hard about this issue and wanted to offer something hopefully more helpful before I replied again.

The screenshot below is from a file shot a couple years ago, outside of DST (October.)

The time and timezone were set correctly in the camera at the time of the shot. If I had set these incorrectly at the time, i could use the tools in iMatch (Modify EXIF date and time) to correct my mistake. If these are not available then perhaps GPS times could be used to populate the other IPTC / XMP fields (maybe that should be a first choice if available) and if not that, then whatever the camera is set to. In any event, whatever time is set in my computer, months or years after the fact, when I rescan and use force update, it should not in my mind be adjusting the time.

in the example below the -04:00 time zone is being grabbed from Windows when I do a Force Rescan on the file (because currently DST is on.) Just because it's summer (DST) now does not mean it was when the shot was taken. The time however was not recalculated, leaving me with a time stamp that has the correct time in a completely irrelevant time zone; in other words, the time is just wrong.

The 12:00AM in the composite Date/Time Original seems to be there because there is no time data in the field. I've seen this in other fields that I can edit, though in this particular case I am assuming this as I can't edit the composite field. The other fields still aren't repopulating after a force update rescan.

Just in case this is relevant, I have preferences set as follows
Protect unwritten metadata   No
Preserve date/time original file   Yes
Keep existing XMP   No

I've tried entering different IPTC Time Zones in preferences to see if that had an impact, but it seems to have no effect.

Still loving the program, but this time thing is really bugging me.

[attachment deleted by admin]

[jch2103]

Dates and times are not well addressed by current metadata standards. To begin with, time zone isn't part of the EXIF standard (although some camera makers store it somewhere in proprietary metadata). Consequently, when you import an image it has date and time information but not time zone (perhaps some camera makers' proprietary software does this, but I can't confirm).

Consequently, IMatch and other software has no notion of what time zone the image was taken in. And as you know, time zones are very complicated, dependent on geographic location and with specific (and subject to change) start and end times for daylight savings time. This wouldn't be so bad if EXIF had a notion of time zone as set by the user in the camera, but it doesn't.

A special case is situations where the camera has a built-in or linked GPS that can directly record location and GPS time. However, the GPS tags don't record time zone either (it's implicitly UTC 0 or Z).

Once an image is on a computer, it can be assigned a time zone using XMP or IPTC standards (although IPTC is no longer a current standard per IPTC/Metadata Working Group). [Note, though, that only some metadata tags support time zone information.] But then of course the questions are who (or what, i.e., the computer?) should assign a time zone and what it should be. One option, for example, might be to have the software calculate time zone based on the EXIF time from the camera based on offset from GPS time, assuming GPS data is available. Another option might be a script for a specific camera make/model that reads the proprietary time zone tag and uses it to add time zone to standard date/time fields. Depending on the user's needs there can be different answers to these questions.

Mario changed date/time handling in late beta versions of IMatch to allow time zone information to be added in the metadata editor (again, of course, only for tags that support TZ). I think this was a significant improvement, but it can't automatically handle all user needs.

As has been said on this forum many times (pun not intended), metadata is a mess! And date/time metadata is even worse...

[J.D. McDowell]

I agree completely.

I also think what Mario has done to try and accommodate this is helpful.

I would however just like the program to not alter my times if for whatever reason I need to rescan a file. I'm happy correcting any issues manually with the tools available.