The viewer's "x years ago" info sucks ;-)

Johannes Zarl-Zierl johannes at zarl-zierl.at
Tue Apr 11 23:43:18 BST 2023


Hi Tobias,

> - For easter 2022 (2022-04-17), I get "11 months ago"
> - For easter 2021 (2021-04-04), I get "2 years ago"
> - For easter 2020 (2020-04-12), I get "2 years ago"
> - For easter 2019 (2019-04-21), I get "3 years ago"
> 
> You see the problem?

Just as you guessed, this stems from the initial design of that code as a 
means to display the age of a person. With birthdays, it totally makes sense 
to say "1 year old" when the person is 1 day from their second birthday. 

> The longer the date is in the past, the more it's not about the date being
> exactly one day after the date in question or not. Easter 2019 IS four years
> ago, even if the photos have been taken on April 21, and now we only have
> April 9.
> 
> [...]
> 
> For durations that are less than e.g. 2 years ago, we should add exacter
> descriptions, like "1 year and 10 months ago". But as the distance grows, we
> need to be more fuzzy. Like "Ca. 2 years ago", even if we are like one
> month off. We could also add some classification like "x 1/4", "x 1/2" and
> "x 3/4", with proper ranges. And with added attributes like "Ca." and
> "Almost". Of course, we also need the "Exact" case, for some fixed date
> (like Christmas or such).

I have a hard time coming up with a scheme that expresses the colloquial 
description that one might use. What I can say, though, is that I really don't 
like adding special cases for any specific dates like Christmas.

A quick and easy way would be to just use floating point numbers and say things 
like "1.83 years ago". This would avoid loss of information while still being 
somewhat intuitive to grasp, and it would work the same for 1 year as for 100 
years.

I would implement this as follows:
less than 1 month: X days ago
less than 1 year: X months ago
at least 1 year: X years ago 
, where X has two decimal places.

> However, I think that the current state of how we do it is quite messy.
> Looking into Utilities/DescriptionUtil.cpp, multiple class definitions and
> implementations are mixed inside one cpp file, the code is really hard to
> read (at least for me), and I think the classes used don't really fit for
> what I would do.

If one moves the relevant info from dateDifference into the AgeSpec class, we 
have all the necessary info there to implement this.

> I'm thinking of adding one more versatile "time interval" class that either
> can return an exact difference, or a fuzzy one, depending for what we want
> to use it. And there's as it seems only two cases: The age of some person
> in years, or a period of time that has passed since a photo has been taken.

That is basically what the AgeSpec class does. The only problem with the class 
in its current state is that it lacks the exact time interval because the 
information was discarded by the dateDifference() function. But that can be 
remedied...

Cheers,
  Johannes





More information about the KPhotoAlbum mailing list