Date fallback should be the earliest between creation and modification dates

[Chuckame]

The bug

I have thousands of original photos without exif tag coming from many people, and many of them (maybe 80%) has a modification date before the creation date (the rest has identical creation and modification dates). Sadly, immich is by default (after exif tags) just using creation date, but it seems that the creation date can be far after the real original date, which is in my case the modification date.

It's a behavior of windows when copying and not moving files, it changes the creation date while keeping the modification date intact, which seems logic as the file is created at the time of the copy, while there is no file change so the modification date remains the same.

It would be easily fixable by taking the earliest date between the creation (which could be the original date or the copied date) and the modification date.
Here is the faulty line:

immich/server/src/services/metadata.service.ts

Line 592 in 6080e6e

this.logger.warn(`Asset ${asset.id} has no valid date, falling back to asset.fileCreatedAt`);

As a side effect, to fix the already uploaded photos, the Metadata re-scanning job should also rescan the crearion/modification dates.

The OS that Immich Server is running on

Debian

Version of Immich Server

v1.123.0

Version of Immich Mobile App

Doesn't matter

Platform with the issue

• Server
• Web
• Mobile

Your docker-compose.yml content

Doesn't matter

Your .env content

Doesn't matter

Reproduction steps

1. On windows (and probably any system), copy an old photo without exif tag
2. Then upload the copied photo
3. You should see the copy date in photo's date instead of the original date (which is the modification date)
   ...

Relevant log output

No response

Additional information

There is many apps dropping the exif part for privacy, like Facebook, Facebook messenger, WhatsApp, mms, and more. Because of those, immich do the fallback.

[bo0tzz]

Filesystem dates are handled pretty arbitrarily and in Immich we just use it so there's -something- to show. If you have knowledge of exactly what field you expect to be correct, you should correct the EXIF metadata on your files using exiftool.

[Chuckame]

I'm not challenging a way to generate exif tags, this is not the subject. I'm challenging the fact that any user which is copying a file on a computer will change the creation date. As immich is using a date fallback, the used date is definitely the wrong date, as nearly all the users are copying photos on their computer when organizing files.

[bo0tzz]

I get that, what I'm saying is that these filesystem dates have inconsistent behaviour that makes them useless for tying any expected behaviour to. For example, on a linux system a copy changes the create date as well:

/tmp/tmp.LvtbDfonfp ❯ touch foo

/tmp/tmp.LvtbDfonfp ❯ cp foo bar

/tmp/tmp.LvtbDfonfp ❯ stat foo bar
  File: foo
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: 0,42	Inode: 388         Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/    boet)   Gid: ( 1000/    boet)
Access: 2024-12-22 13:08:51.455434320 +0100
Modify: 2024-12-22 13:08:48.118544039 +0100
Change: 2024-12-22 13:08:48.118544039 +0100
 Birth: 2024-12-22 13:08:48.118544039 +0100
  File: bar
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: 0,42	Inode: 389         Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/    boet)   Gid: ( 1000/    boet)
Access: 2024-12-22 13:08:51.455434320 +0100
Modify: 2024-12-22 13:08:51.455434320 +0100
Change: 2024-12-22 13:08:51.455434320 +0100
 Birth: 2024-12-22 13:08:51.455434320 +0100

So the current behaviour is a somewhat arbitrary pick, changing it to another field would be just as arbitrary, and the proper solution is to write the field that you know is right in your particular case to the EXIF data.

[Chuckame]

As we know that any system copy works like that, and it's an arbitrary pick, why not really picking the earliest? At least it will fix 99% of the users which get data from friends or family from an old external hdd, where anyone is copying over and over the photos. Using exiftool requires tech skills, while trying to take a better fallback will solve this so common issue and without any tech skill.

Maybe the discussion could be shared between multiple users to check that it's not "my particular use case".

I can make a PR if needed btw.

[mertalev]

I think this is not really a bug and more of a feature request. I don't see a harm in taking the earlier date, though. Happy to review a PR for it if you're able.

It does make me wonder - when is the file modification date not a better choice than file creation? If the latter gets messed up by a copy and the former doesn't, then isn't it better to just use the former?

[Chuckame]

Taking only the modification date can lead to take the date when you cropped, rotated or any real change. The earlier is like trying the max to not have wrong dates. But for sure, taking this after a really modified photo which has been copied before will finally have the wrong date anyway.

I'll make the PR, it seems not that complicated. Can we re-open this issue if we agree on that to link the PR on this issue ?