[OFFICIAL] Request for Comment: Date Created or Date Last Modified?

[Mario]

Since IMatch 3 times, IMatch uses the last modified on disk timestamp if a file has no other usable metadata. See How IMatch uses Date and Time Information for details.

This was implemented that way because at that time (and in the years following) users who dealt with files without metadata expected the global File.DateTime in IMatch to be the date and time the file was last modified.
Note: This effects only files without any usable metadata and for which the user does not fill in the date subject created or date created XMP tags in the Metadata Panel.

This causes confusion when users:

a) work with files without usable date & time metadata
b) they don't set the date subject created or date created manually
c) they keep the option "Mark file as pending write-back" set to "No" (the default)

In this situation, every change they make to the file on disk (write-back in IMatch, editing in another application) will reset the date and time IMatch uses to whatever the last modified timestamp in the file system is.
And users wonder why.

I first tried to overcome this by letting IMatch mark the date subject created / date created filled during import as modified.
The idea was to automatically persist these initial timestamps in XMP by enforcing a write back at some time. After the write-back, the files have XMP data and proper timestamps which no longer change when the file is modified.

Unfortunately, this was not well received. Because it caused hundreds or even thousands of files to be marked as pending write-back after import (when the files had no usable timestamps).
So I've had to add the option mentioned in c) above and set it to No by default.

For IMatch 2021 I'm thinking to no loner use the last modified timestamp as the last resort fallback, but the date created timestamp. Which may be identical or different from last modified.
What I don't want is to add yet another option. IMatch has too many options already, and new users often give up considering IMatch when they see the many options IMatch already has. I try to simplify things, not complicate things.

Question:

Which timestamp to use as the fallback when a file has no usable metadata timestamp?

A => Last modified in the file system
B => Created in the file system

Please reply below.

[thrinn]

Which timestamp to use as the fallback when a file has no usable metadata timestamp?
A => Last modified in the file system
B => Created in the file system

Clear answer: B. If no valid EXIF/XMP timestamp is available, the creation date could be seen as the most valid approximation of the "birthday" of this file.
What I don't want is a file jumping through the timeline just because some application modified it. So, option B sounds much more logical for me.

[PandDLong]

B

As this is consistent with the priority of chooses the timestamp if there is a valid EXIF record.  Makes it a more intuitive approach (IMO) as well as stopping a file from moving in the timeline.

[ubacher]

B, clearly

[bekesizl]

B seems to be a more stable solution.

Maybe add a collection to list this type of files, until they get a date assigned.

[afengler]

B

[Jingo]

Agree with everyone.. B for sure.

[JohnZeman]

I agree with everyone else, B.

[jch2103]

I agree: B.

[BanjoTom]

I'm with everyone else: option B is the way to go!

[Tveloso]

I agree with B also.

I recall though, that someone here once pointed out that there can be instances where Windows will generate a new Create Date, such that the file will actually have an older Modified Date than its Creation Date. 

I know that I've seen image files in that state in the past (prior to adding them to IMatch)...I recall sorting by the Last Modified Date in Windows Explorer for whatever I was doing (having decided that was actually the correct "Creation Date" as it was earlier), but then needing to switch back to Creation Date for the majority of the photos.

So as Thorsten says:

...the creation date could be seen as the most valid approximation of the "birthday" of this file.

That's a great way to put it!

[PaulS]

B

[chupacabra]

B

[ghundt]

I think this happens whenever files are copied using Explorer, such as to back them up to another disk, I guess the logic being that this does "create" a new instance of the FILE, containing the unmodified original content. Perhaps the choice should be to use the oldest date?

I recall though, that someone here once pointed out that there can be instances where Windows will generate a new Create Date, such that the file will actually have an older Modified Date than its Creation Date. 

I know that I've seen image files in that state in the past (prior to adding them to IMatch)...I recall sorting by the Last Modified Date in Windows Explorer for whatever I was doing (having decided that was actually the correct "Creation Date" as it was earlier), but then needing to switch back to Creation Date for the majority of the photos.

[Aubrey]

B:
i.e., the birthdate of the file.

Aubrey

[Mario]

I think this happens whenever files are copied using Explorer, such as to back them up to another disk, I guess the logic being that this does "create" a new instance of the FILE, containing the unmodified original content. Perhaps the choice should be to use the oldest date?

Yes. And probably also when the file is re-saved in an editor (depends).
The general idea is to actually set a date created / subject created in IMatch - and not to rely on the file system date.
This is all about the last-resort fallback when the file has no metadata and the user does not want to set a timestamp at least once to anchor the file on the timeline.

[mastodon]

Is there a possibilaty to make an EXIF "date created" tag parallel this (making an XMP tag)? Mostly I set an EXIF date created tag with Imatch for jpg-s without any EXIF/XMP timestamp (mostly from Facebook), because a lot of other software still rely on it.

[meyersoft]

Agree, B

[Mario]

Is there a possibilaty to make an EXIF "date created" tag parallel this (making an XMP tag)? Mostly I set an EXIF date created tag with Imatch for jpg-s without any EXIF/XMP timestamp (mostly from Facebook), because a lot of other software still rely on it.

Please don't. IMatch automatically updates EXIF data from XMP data during write-back. This is why you always set the XMP date created / date subject created in IMatch and let it take care for updating the corresponding XMP (and legacy IPTC if existing) data during write-back. This ensures that relevant timestamps in EXIF, legacy IPTC and XMP are synchronized.
IMatch never uses EXIF timestamps directly, it fills the XMP timestamps from them during import.

I recommend reading: How IMatch uses Date and Time Information.

[DigPeter]

Yes - B

[voronwe]

I think this happens whenever files are copied using Explorer, such as to back them up to another disk, I guess the logic being that this does "create" a new instance of the FILE, containing the unmodified original content. Perhaps the choice should be to use the oldest date?

I recall though, that someone here once pointed out that there can be instances where Windows will generate a new Create Date, such that the file will actually have an older Modified Date than its Creation Date. 

I know that I've seen image files in that state in the past (prior to adding them to IMatch)...I recall sorting by the Last Modified Date in Windows Explorer for whatever I was doing (having decided that was actually the correct "Creation Date" as it was earlier), but then needing to switch back to Creation Date for the majority of the photos.

I found out that for example Total Commander had this settings, that if you copy a file from a different location (e.g. Network or USB-Stick) to your machine, it changes the date to the time of the copy, which drove me crazy until I found out.

When it is only for Files without any Metadata, I would also clearly go for B.

If you need to find out which file was changes last, you have to use the Explorer and sort by Date

[Mario]

If you need to find out which file was changes last, you have to use the Explorer and sort by Date

Or you create a sort profile in IMatch which uses the "modified" date or the "create date" based on the file system timestamps. IMatch has all that built-in, even if you usually don't need it.
You can sort by any of the ~14,000 tags IMatch supports 

[HaWo]

B

[voronwe]

If you need to find out which file was changes last, you have to use the Explorer and sort by Date

Or you create a sort profile in IMatch which uses the "modified" date or the "create date" based on the file system timestamps. IMatch has all that built-in, even if you usually don't need it.
You can sort by any of the ~14,000 tags IMatch supports 

Even better
I was only unsure what possibilities you have with files without metadata - because I simply do not have such files in IMatch

[Carlo Didier]

Although I don't have any such problems, if I had, I'd also prefer solution B.

[AlanS]

B Please

[erichaas]

B

[sinus]

Another B, clearly.

[imfan]

 B

[lbo]

Which timestamp to use as the fallback when a file has no usable metadata timestamp?

A => Last modified in the file system
B => Created in the file system

As written in previous postings, neither is stable:

Modifying the file contents changes mtime and copying or moving between partitions changes ctime.

The "correct" choice completely depends on the individual situation.

Therefore, switching from mtime to ctime will be "unexpected" to many users and very likely cause trouble.

Consider files copied from external storage to the local disk before importing: Using ctime would be a stupid idea.

Maybe the best guess is to use the older of both dates.

One or two warning(s) to the user after the initial import might be also good idea.

"Files with missing time metadata imported. Save time information to metadata as soon as possible."

Then the user can choose whether to use mtime or ctime to set metadata according to his knowledge about the history of the imported files.

[Mario]

Consider files copied from external storage to the local disk before importing: Using ctime would be a stupid idea.

This may depend on the NAS or tool used, surely?
Did you see it happend that the creation time of a file was actually newer than the last modified time? I think this would be unlikely.
Using the older of the two of course would handle that.

What I don't want is more options.
Or more messages confusion (especially new) users.
There are plenty of messages already displayed when a user creates a new database and ingests the first set of files.

Maybe a corresponding notification in the notification area will do the trick, with a link to the help system.
This is less intrusive than a message box, and one of the main reasons I've added that feature.

[Rene Toepfer]

For IMatch 2021 I'm thinking to no loner use the last modified timestamp as the last resort fallback, but the date created timestamp. Which may be identical or different from last modified.
What I don't want is to add yet another option. IMatch has too many options already, and new users often give up considering IMatch when they see the many options IMatch already has. I try to simplify things, not complicate things.

I am a Newbie to IM2020 and I like that it is highly customizable. This is one of the main reasons for me to buy IMatch. I do not want to have an "apple-lized" software. Maybe it is a good approach to think of restructuring the options. For me they are to wide spread over the software, some are in the settings others in the tool settings.

Which timestamp to use as the fallback when a file has no usable metadata timestamp?
A => Last modified in the file system
B => Created in the file system

B

[Carlo Didier]

Did you see it happend that the creation time of a file was actually newer than the last modified time? I think this would be unlikely.

I have actually seen that quite often, at home and at work, with local disks and network paths. It's Windows that does it. Copying a file creates a new file, hence a new date_created timestamp, but it retains the last_modified timestamp of the original file.

[Mario]

Oh, well...

I will then implement this change by using the older of the two {created|modified} timestamps.
This should do the trick and hopefully does not break to much out there...

[lbo]

Consider files copied from external storage to the local disk before importing: Using ctime would be a stupid idea.

This may depend on the NAS or tool used, surely?

no, it's as I wrote: "copying or moving between partitions changes ctime". To be more precise:

• By copying, the new file gets "now" as ctime even if you copy it from c:\foo to c:\bar.
• Moving doe not change ctime as long as the file stays on the same partition.
• Moving between partitions always makes ctime "now", even if both partitions are on the same physical HDD.

Using an "unusual file manager" might yield different results.

Moving between directories on the same NAS share might keep ctime if Windows is able to initiate a remote move. But I'm not sure and that's likely not the question here.

Oliver

[Mario]

I have figured this out. Once you look for it, you see it.

This unfortunately creates the situation that you have a file created today, but modified last year.
What date to use to fill in date subject created in that case?

My idea was to use the older of the two dates. So, in the case above, the last modification date (last year) would be used.
But I'm sure there are users who would prefer to use today in that particular case. Or always the last modified. Or always the created...

But I don't want to make this an option with four or more settings. I want no option at all. So, which one to pick?

[sinus]

I have figured this out. Once you look for it, you see it.

This unfortunately creates the situation that you have a file created today, but modified last year.
What date to use to fill in date subject created in that case?

My idea was to use the older of the two dates. So, in the case above, the last modification date (last year) would be used.
But I'm sure there are users who would prefer to use today in that particular case. Or always the last modified. Or always the created...

But I don't want to make this an option with four or more settings. I want no option at all. So, which one to pick?

Crazy what Windows does.
Hm, if a file has been created 2005 and I have modified it 2021, and now I move this to the IMatch-computer, I want for sure not a create date from 2021.
Then I would that the create date would be 2005.

Hmm, really difficult. 

[lbo]

Crazy what Windows does.

It's the same "logic" as applied for drag and drop with the mouse. Did you notice the difference between "same partition drag/drop" and "different partition drag/drop"?

Dragging in the same partition moves by default (override with Ctrl). Move doesn't then change timestamps and ACL *) - it's still the same file in the same HDD bytes, only pointers are changed. This way you can move a 1TB file in a fraction of a second.

Dragging to a different partition copies by default (override with Shift).

Moving a file to a different partition can't be done by simply changing directory entries, it must be copied to the new place on the HDD. ACL inheritance applies, IOW the file could inherit a new ACL from the target folder. Then the original file is deleted. Microsoft decided that this file has been "created" now.

Oliver

*) The latter can be "surprising" if you drag a file into a folder with different ACL.

[Tveloso]

I will then implement this change by using the older of the two {created|modified} timestamps.
This should do the trick and hopefully does not break to much out there...

This seems like the best solution...

When IMatch has had to fall back to using the FileSystem Dates (because the file contains no Date Data), in the "standard case" (where Cdate precedes Mdate), this will keep the Date "more stable".

And for the other case:

This unfortunately creates the situation that you have a file created today, but modified last year.
What date to use to fill in date subject created in that case?

...IMatch will behave as it does today.

In that latter case (where that earliest available date came from Modified Date), once the file is modified again, that Earliest Date will have been lost.

But even in the former case (where a subsequent modification will not change the Date IMatch is using for the file), that date may not actually be correct the one (since. The file lacked Dates, and IMatch had to fall back to the FileSystem), so the Warning message would be a valuable addition:

Maybe a corresponding notification in the notification area will do the trick, with a link to the help system.
This is less intrusive than a message box, and one of the main reasons I've added that feature.