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

[Tobias Leupold]

Am Freitag, 14. April 2023, 08:27:20 CEST schrieb josephj at main.nc.us:
> Nerd answer: Just provide a place to add a strftime format string and make
> everybody happy (at least those who know what strftime is). :)
> 
> Joe

But that would not allow heuristics to distinguish short periods of time from 
longer ones. And this is IMHO something that should not be configurable. Or at 
least, adding such decision rules in a configurable way would require a quite 
big and complex configuration dialog. I'm not sure if this would be "too much" 
for the aber KPA "User" (no developer, no coder, not even an enthusiast) ...

> 
> > Am Mittwoch, 12. April 2023, 13:27:11 CEST schrieb Tobias Leupold:
> >> Am Mittwoch, 12. April 2023, 06:22:07 CEST schrieb Per Funke:
> >> > "1.83 y/m/d ago" is unconventional but attractive
> >> > IMHO,
> >> > Per Funke
> >> 
> >> Hmmm ... I think this would be too unconventional, especially facing the
> >> fact that a year is not divided into decimal units (it's 12 months after
> >> all, not 10).
> > 
> > Maybe it's just me, but using decimal representation for time units does
> > not
> > seem so odd. "1.83 years ago" is easy to read and understand, even if one
> > does
> > not intuitively realize that it is the same as "1 year, 9 months, 28 days,
> > 19
> > hours 20 minutes ago".
> > Plus: it eliminates the need to come up with a universal way to shorten
> > this
> > (should it be 1 year, 10 months, or 1 year, 9months, almost 29 days?).
> > 
> > Would a hybrid approach work better in your opinion? I.e. "1 year, 9.96
> > months". This does arguably combine the best and worst of both approaches:
> > 
> > - ugly to compute (depends on the length of the month)
> > - decimal point in non-decimal unit (e.g. "4.6 months")
> > + canonical representation (always "X years, Y months", no complicated
> > heuristic needed)
> > + more intuitive than pure decimal notation ("1 year 9.96 months ago" vs
> > "1.83
> > years ago")
> > 
> >> Any objections if I implement this in a way I would expect it to be
> >> (both
> >> for birthdays/ages and timespans) soonish and you all have a look at it
> >> then?
> > 
> > Sure - I'll gladly take a look at that work branch and comment on it ;-)
> > 
> > Cheers,
> > 
> >   Johannes