Incomplete dates

[chrishas35]

For some photos, pre-digital or digital where original metadata has been lost, I may not have the precise date/time it was taken. I'd still like these to have some level of date information though. ISO 8601 supports various level of partial dates (YYYY or YYYY-MM), but it'd also be nice to say "it was in the YYX0 decade" or even "it was in the YY00 century", so associating some level of precision to the fuzzy date would be good. One step further though I could also see benefit in providing a "fuzzy" range, for example you know they lived in this house from YYYY-ZZZZ but not much more beyond that can be determined from the photo.

It would also be beneficial able to sort photos relative to one another when there are incomplete dates. This could either be against other incomplete date photos, or (and this may be aided by range support) against a photo with a complete date.

[aisbergde]

I don't get the whole idea.
I also have this kind of assets, but what would be the features in immich?

• Search and find them?
• How to sort them in the timline, if they should represent a range?
• about comparing with other assets at the same time: I would say, this could be a job for some external software to manage photos and their metadata. How this should or could look in immich? immich is showing thumbnails or single photos.

[chrishas35]

My main point would be the remove ambiguity from the date. The solution I've seen most suggest for this is to just decide to pick a date, for example, January 1, YYYY to represent a year. But immich will display that full date (and time for that matter) and it becomes a "was this really January 1, YYYY or was it some time in YYYY?" IMO this really starts to break down with wider ranges, such as multiple years. If there are other workaround, I'm happy to give them a shot for the use-case, but the one I see over and over is less than ideal IMO.

Even an external solution managing the metadata can't really solve that ambiguous display issue as immich is always going to display out the full date/time currently. This may be viable if, at a minimum, it was able to provide a precision to a date (day, month, year, decade, etc.) and adjusting the immich display accordingly would be helpful. However, as noted this breaksdown for something that spans multiples.

[dkbarn]

I would also like to see this feature, as I use Immich to store digitized scans of old photos. For most of these photos, the exact date is unknown, and can only be inferred from context or maybe from a caption, but these captions often say things like:

• Christmas 1967
• Spring 1971
• January 1980

I want to capture these dates in Immich, so that I can sort and search for them by date, but I don't want to arbitrarily make-up fake values for timestamp components that I don't actually know, simply because Immich requires that a complete YYYY-MM-DD HH:MM:SS be provided.

The best way I can think to support this is to allow for an upper and lower bound of each photo timestamp, to define a possible range of dates.

In terms of how searching and sorting would function with this feature, it seems to me that searching would be pretty straightforward -- you can still search for a date and if that date appears somewhere within the min - max range of a given photo then it matches the search.
For sorting, you could choose to sort photos by their min, max, or midpoint value. I don't think it's especially important which. For photos that have a known timestamp, the min and max are the same, so it makes no difference.

[radh21301]

I find this feature request very confusing. And in my opinion, it's not something that an app like Immich is supposed to solve.

Firstly, Immich is not really enforcing the YYYY-MM-DD -HH-mm-ss rule, is it? The EXIF field requires that structure (you could force the field to take partial dates, but many programs don't accept partial dates), and immich has to respect that. Say Immich goes ahead and implements what you ask (Summer of 1965 or something), then it cannot be stored in either the asset's EXIF field or the accompanying XMP sidecar file. What this would mean is that -> whatever edits you make with Immich has to be stored in the Immich database, and cannot be used with other tools if you decide to migrate. That is not a good design.

To me, the best solution looks like setting the date like you suggested -> The best guess you can make. If you have no estimate, then January 01, YEAR, midnight (00:00:00). If you have a series of photos you digiitzed, and want to keep them in the correct order-> add a second to each photo (you can ask exiftool to sort by filename and add one second to each image). This would keep all your images in the correct order when you view them on the Immich timeline.

And if you want to say that it was Spring of 1995 or something, just add it to the description. OR add a tag that says 'date is tentative' or something. Description and Tags can be stored in the asset's metadata, so it will be available when you migrate.

References:
https://exiftool.org/forum/index.php?topic=11575.0
https://exiftool.org/forum/index.php?topic=3956.0
https://news.ycombinator.com/item?id=34377584

[dkbarn]

The goal here is to have a way of keeping track of incomplete dates, and visually distinguishing them from dates that are complete. I agree that deciding how complete and incomplete dates should be compared when sorting is a challenge, but the exact mechanics of this I think are less important so long as a date of "1980-01-XX" appears somewhere in the timeline alongside other photos in that month.

I agree with you that I could solve this problem by simply inventing my own convention with what's already available -- for example, represent January 1980 as 1980-01-01 00:00:00 with the text "January 1980" written into the description or in a tag, or by incrementing the seconds to :01 to signal to myself that this is an estimated date. But these are all hacks and workarounds, so the intent behind this discussion is to request that Immich support this concept officially, to eliminate the need for hacks or workarounds.

[radh21301]

Okay. What do you mean by visually distinguishing them - a small icon or something on the image thumbnail? something like that? Wondering how that distinguishing factor helps you? Sorry, I am not able to clearly envision how this feature would look like inside Immich. Maybe someone with more experience can add to this.

P.S. From my experience, I have found that it is essential for photo management apps to stick to established standards. Purely for selfish reasons, the app you use today might not be there 10 years from now. So, any edit you make that is not a standard would essentially be lost. So, bending our individual workflows (those hacks) to accommodate these standards makes it future-proof.

Edit: I actually see your use case when I think of an image that was taken in the 1800s. But now it could be 1899 or 1800..That is a huge spread! But still I am not able to think of a future proof way - other than setting the date to 1800 Jan 01 midnight AND adding some information to the description

[aisbergde]

what I could imagine:
if the time is 00:00:00 there could be an optical indicator, that the asset has only a date but not a time.
and if it is the 01 day of the month without a time, they user could interpreted this as month without date. But this can't be a general concept: how to distinguish between day accuracy, month accuracy or year accuracy?

Maybe the combination with an accuracy tag could be used. But I agree, it would create a dependency from immich.

A more flexible way would be to define a list of tags (and optionally associated icons) to be shown on assets. This would allow an optical indicator - for whatever user defined tags.

[dkbarn]

What do you mean by visually distinguishing them - a small icon or something on the image thumbnail? something like that?

Actually I just meant that the way that Immich displays timestamps should reflect the accuracy value that has been set for it.

Instead of this:

It would show as this:

so that viewers can see that this photo in fact was not taken at midnight on New Year's Day, it was simply taken sometime in the month of January.

[CorentinB]

It would show as this:

so that viewers can see that this photo in fact was not taken at midnight on New Year's Day, it was simply taken sometime in the month of January.

This would be absolutely great, good example. I have many such cases where this would be very useful, because I use Immich to store and sort family pictures that I digitize.