Synchronizing Dates between IMatch and Windows File Explorer

[Damit]

I cannot figure out what File Explorer uses to field Date, Date Taken, Create Date and Date Modified. I cannot get them to line up with the information I see in IMatch. The only thing that seems to line up is Date Modified.  I thought Windows used EXIF data, but apparently not? I changed to Create & Date Subject Created Dates with the Time Wiz app, all based on the date modified, but now the date created in Windows File Explorer does not line up with the Date Created in IMatch, as they seem to not be referencing the same metadata.
I then used the Metadata Analyst to try to figure things out.  I did see Quicktime Data but that does not correspond to either of the dates.

Does anyone know what windows uses for these date categories and how I can get I match to change them? I would like them to match so if someone I give my photos to has nothing other than File Explorer, the can still sort them in chronological order using Date Created. Other workarounds are welcomed.  Maybe I can use another field, but I cannot figure out how to get File Explorer to list the Date Subject Created.

[thrinn]

When I lool at the properties of an ARW or JPG file in Windows Explorer, I see the relevant dates in the "Details" tab. They correspond to the metadata of the photo. The "General" tab, on the other hand, only refers to file system dates, which makes it more or less useless. (The screenshot are from my German Windows version, but you get the idea...)

A very simple solution: include the date the photo was taken as first part of the file name. That is what I do. A simple sort on filename will then put the files in the right order. Even on Windows or on an Android tablet.

[philburton]

I use EXIFToolGUI to manage all those dates.  I didn't even know about all the different date fields until I used EXIFToolGUI to explore photo file metadata.

This tool hasn't been updated for years now, but it runs perfectly well under Windows 10 64, 2H22 release.

[Damit]

Thanks for the pointers .  It seems that the Quicktime>Line item>Creation Date holds the true create date for iphone .mov files.  The metadata Analyst helped me find that.  I am still trying to figure this out and if I find any more useful information I will report back for anyone who may find this thread later and need some guidance.

[Mario]

I use EXIFToolGUI to manage all those dates. 

Please be aware of How IMatch uses Date and Time Information
All you need to do in IMatch is to maintain the "Create Date" and "Date Subject Created" and leave the rest to IMatch and ExifTool. For typical date-related issues to fix (like wrongly set camera clock, time-zone shifts and suchlike) use the comfortable IMatch Time Wiz app.

Don't bring in external tools into the mix or use the ExifTool Command Processor. Many timestamps are linked to other timestamps (XMP, legacy IPTC, EXIF, GPS) and have to be synchronized properly. IMatch does that with the help of ExifTool during write-back.

When you set a time stamp or two in an external tool that does not do the sync correctly, problems will occur.

[Mario]

Thanks for the pointers .  It seems that the Quicktime>Line item>Creation Date holds the true create date for iphone .mov files.  The metadata Analyst helped me find that.  I am still trying to figure this out and if I find any more useful information I will report back for anyone who may find this thread later and need some guidance.

Apple products are always special...

Please read How IMatch uses Date and Time Information where I explain how IMatch "produces" the important "Create Date" and "Date Subject Created" time stamps from metadata in your files. And how IMatch produces the global File.DateTime, which is paramount for all time-based features in IMatch, from sorting to the Timeline View to Events.

QuickTime files contain a whole bunch of different time stamps, for the container, tracks, proprietary Apple maker notes and all that. The above documentation lists which of these tags IMatch uses, and in which order, based on existence, to figure out the best time stamp.

If you have a case where the "Create Date" and "Date Subject Created" (in the Default layout in the Metadata Panel) seem to be wrong or the File.DateTime in UTC is wrong, let me know and send me a sample file so I can look at what Apple has written to the file.

As thrinn pointed out, Windows Explorer shows file system timestamps on the General tab and some metadata time stamps on the Details tab. Which metadata Windows Explorer uses for different file formats is not really documented. It seems to use native EXIF data, ignoring XMP data (?). For video files or other file formats, it's just guesswork which metadata Windows Explorer decides to display.

In no situation you should allow Windows Explorer to modify metadata. It is known for not synchronizing metadata between EXIF/GPS and XMP and for damaging maker notes. Leave this to IMatch and ExifTool.

[Tveloso]

It seems that the Quicktime>Line item>Creation Date holds the true create date for iphone .mov files.

You may not be able to rely on that tag containing the correct CreateDate and/or being present in the file.  While it's true that my most recent iPhone Videos do contain the correct TimeStamp in QuickTime::ItemList\creationdate\CreationDate\0, this tag has not always been present over time.  It seems that Apple has stored (and/or ExifTool has delivered) the "true TimeStamp" in other tags (with a similar names).

For a period of time, the "correct" Tag to use was QuickTime::UserData\date\DateTimeOriginal\0.  When this tag was present in a .MOV File, IMatch was not arriving at a correct File.DateTime for that file, so I created a Metadata Template to copy its value into Create Date and Date Subject Created.

Spot-checking some of my older iPhone Videos, I found that the "correct" TimeStamp has been delivered in QuickTime::ItemList\1.4\CreationDate\0 and QuickTime::ItemList\1.5\CreationDate\0 (and there are probably others).  I believe that when one of these two tags was present, IMatch did arrive at the correct File.DateTime for the File.

And all of these Tags:

    QuickTime::ItemList\1.5\CreationDate\0
    QuickTime::ItemList\1.4\CreationDate\0
    QuickTime::UserData\date\DateTimeOriginal\0
    QuickTime::ItemList\creationdate\CreationDate\0

...appear with the exact same identifiers in the ECP:

    [Keys]              - Creation Date

...which adds a bit to the confusion.

[Mario]

IMatch looks at a variety (14 or so) of QuickTime tags to figure out the timestamp to use.
"QuickTime::ItemList, QuickTime::MovieHeader, QuickTime::UserData etc.
QuickTime files may have CreationDate in Keys and in MovieHeader, and often with different times!
There is even an IMatch option to favor the creation date over the other date, since it is sometimes "more correct".

Apple moved around the tag in which their phones and other devices store dates and times a lot over the years, making this a somewhat moving target. Versioned QuickTime data like you mention (the \1.4 and \1.5 sections) adds even more complexity.
Unnecessary to say that Apple does not use the standard XMP created/date subject created timestamps and that a MP4 file may contain multiple data streams with different timestamps.

If you have an Apple video file which does not produce the correct timestamp in IMatch, please SEND ME A SAMPLE and tell me which would be the correct time.
I can then add another tag to the "look into" collection IMatch uses to determine the File.DateTime for Apple files.

I occasionally update the list of tags IMatch considers for files without EXIF/XMP timestamps like MP4, but it's hard to keep up with the continuous changes Apple and the other smart phone and camera vendors do with QuickTime and other video metadata. Video metadata is an even bigger mess than image metadata. And why device vendors favor custom metadata schemes and maker notes over XMP is a riddle.

On the other hand, considering that Nikon cameras sometimes write an XMP record with time stamps not considering the time zone offsets the same camera has recorded in EXIF (EXIF time is "12:00:00+04:00", but Nikon writes the XMP time stamp as "12:00:00+00:00"), I guess that camera vendors adopting XMP would cause a heap of additional problems, because they would do it half-assed as usual.

[PandDLong]

Does anyone know what windows uses for these date categories and how I can get I match to change them? I would like them to match so if someone I give my photos to has nothing other than File Explorer, the can still sort them in chronological order using Date Created. Other workarounds are welcomed.  Maybe I can use another field, but I cannot figure out how to get File Explorer to list the Date Subject Created.

I had the same goal - sharing with others who only have File Explorer and wanting the correct sort and information on the "when" to be available. 

The complicating factor is that the dates for file creation and modification may be changed by other software after the fact.  As an example, some cloud software will "create" the file and then copy in the contents from your upload - but the create date on that file is now the date you copied it to the cloud. If someone downloads it, the create date stays as per the date uploaded to the cloud.

I think you can customize the settings in File Explorer to display a column for the correct field from the metadata - but I am not certain and I decided that asking others to customize File Explorer didn't seem like a reasonable solution for file sharing.

Like Thorsten (Thrinn), I decided to use the iMatch Renamer to put the date as the first part of the filename, thus I know it is always going to sort correctly and be visible.

Hope that is helpful.

Michael

[Mario]

Windows by default displays only file system time stamps (created on disk, last modified on disk, last accessed).
It supports some metadata time stamps, but you'll have to add the columns yourself (right-click into the columns in detail view to add more columns).

Microsoft is a bit vague about from which metadata they pull this information from. Explorer does not support XMP across all image and RAW formats, so it is probably EXIF. Which will cause problems when you edit time stamps in software and this software only writes the XMP data but does not sync the modified data back to EXIF. IMatch does this right, but don't count on other software to do the same.

If cross-application and cross-platform time stamps are important, the best way is to include it in the file name. Works everywhere, no relying on Windows or Linux or Android / iOS doing the right thing.

[Tveloso]

If you have an Apple video file which does not produce the correct timestamp in IMatch, please SEND ME A SAMPLE and tell me which would be the correct time.
I can then add another tag to the "look into" collection IMatch uses to determine the File.DateTime for Apple files.

Mario, this is probably water under the bridge now.  I have not had an instance where an iPhone Video was indexed with an incorrect File.DateTime in quite a while.  It seems that Apple is finally providing that value in one of the proper locations (where IMatch is looking).  But I'm sure that I still have some "unprocessed" video files from back when this was an issue, if you would still like for me to send samples.

I recall two distinct scenarios (and possibly a third).  For a period of time, iPhone Videos were given either the date that the file was indexed (more rarely, and longer ago - here, I believe that IMatch was simply having to fall back to FileSystem TimeStamps), or as described by PandDLong, the date that the file was "posted" to an iCloud Shared Album (which could be several hours, or a day or more, past when the Video was actually recorded).  I believe that there were also instances where the only available TimeStamp in the Video (aside from that probably Apple-specific "UserData" tag - which did carry the correct time), was the Track Create Dates (which were in UTC), so IMatch used that value directly - which resulted in an incorrect time for my TimeZone).  But this was all before IMatch 2023 and the new treatment of File.DateTime, and many iOS Versions ago as well. 

As Mario has said here (and many times before):

Video metadata is an even bigger mess than image metadata.

...so it's probably not worth analyzing those older files.

But back on the actual subject of this topic, I also store the DateTime Original at the beginning of the FileName (per the advice given here in the community), and have effectively abandoned even looking at the FileSystem TimeStamps.  There was a time that I did try to make sense of them, but I found that while sometimes it was the File Create Date was correct - other times it was the Modified Date (and the CreateDate was later!) - even when I was pulling files off my phone via a cable (and iCloud was not involved).  So I also use the Renamer to name Files starting with the Data/Time, and to move them to their final location on a NAS, once I have finished processing them.

[Mario]

Persisting the "right" time stamp as part of the file name is a proven technique. Just works.

On the other hand, how hard could it be for Apple to store the time the video was created (taken/shot/filmed) in the XMP "Date Subject Created" and "Create Date" tags? This would take all the guesswork out of it, it would work across a wide range of applications, the IPTC committee, the media people and the librarians would be happy. These two time stamps are standardized now for about 20 years. Even Apple might take a minute and take notice

I'm growing more and more tired of sub-standard, sloppy and ignorant handling of metadata in many "modern" and "hyped" applications.
I've just looked at the metadata produced by modern and often hyped applications named "M*" and "E*" and they produce half-arsed metadata, store keywords in proprietary sections of XMP, don't bother to mirror native EXIF data found in the files they manage in the corresponding XMP EXIF sections and whatnot. Although the files have native EXIF/IPTC/GPS data, it does not show in the XMP.
I'm truly unsatisfied. Because this is bad for the users of these services and applications. It locks them in, basically.
Users of these products will run into problems as soon as they try to use the metadata in other applications, on web sites or with services. And the data is not there - because it does no exist or exists only in proprietary XMP name spaces, catalogs or databases...

I'm not saying IMatch is perfect, mind!
But it puts in the extra work to make the metadata you add and edit standard-compliant and independent from IMatch. To make sure your work is safe and works with all other standard-compliant applications and services.

I don't use shady lock-in tactics. I want users to enjoy using my software and that they think that the purchase price and upgrade fees are good investments.

[philburton]

Persisting the "right" time stamp as part of the file name is a proven technique. Just works.

 Even Apple might take a minute and take notice

Sure but Apple has always marched to its own drummer.  Sometimes that is better, sometimes not.  What I hate about Apple is how poorly they support their iPhone and iPad with Windows applications.

I've just looked at the metadata produced by modern and often hyped applications named "M*" and "E*" and they

The suspense is killing me.  What are "M" and "E?"

I'm not saying IMatch is perfect, mind!
But it puts in the extra work to make the metadata you add and edit standard-compliant and independent from IMatch. To make sure your work is safe and works with all other standard-compliant applications and services.

Maybe not, but the more I learn about iMatch, the more I am really impressed with you and your product.

Just compare your well-thought out product, clear documentation, good user interface, with another DAM product also produced by a "one person company" whose name starts with "Pho."  Like night and day, immensely more useful.

Just my two euro-cents, or pfennig, or centimes here.

[Mario]

Maybe not, but the more I learn about iMatch, the more I am really impressed with you and your product.

Just compare your well-thought out product, clear documentation, good user interface, with another DAM product also produced by a "one person company" whose name starts with "Pho."  Like night and day, immensely more useful.

Just my two euro-cents, or pfennig, or centimes here.

Thanks. Much appreciated.
Spread the word  Let other's know about IMatch, e.g. in fora you participate in. Word of mouth is the best marketing I can get.