Re: [PATCH 2/2] --date=relative falls back to "short" format for commits older than a year

Jeff King [off-list ref] writes:

On Fri, Feb 20, 2009 at 01:23:54PM -0800, eletuchy@gmail.com wrote:

quoted

From: Eugene Letuchy <redacted>

In the context of sizing the git blame time column, it doesn't make a
lot of sense to see "12 months ago" next to an exact timestamp +
timezone for something 13 months ago. This commit makes commits older
than 12 months display the date only, not the time.

I think this is an improvement, though I was thinking of taking it a
step further:
...
+		/* Otherwise, years. Centuries is probably overkill. */
+		snprintf(timebuf, sizeof(timebuf), "%lu years ago", (diff + 183) / 365);
+		return timebuf;
 	}
 
 	if (mode == DATE_LOCAL)


but maybe other people actually like seeing the absolute time. I've
always found it jarring when reading relative times (but part of that
_was_ because it was so long and exact).

I agree this is an improvement.  It irritated me, too.  And I do not think
this change falls into the category of bad backward incompatibility.

I was hoping somebody would do a "N years M months", though.

On Sun, Feb 22, 2009 at 05:44:37PM -0800, Junio C Hamano wrote:

quoted

+		/* Otherwise, years. Centuries is probably overkill. */
+		snprintf(timebuf, sizeof(timebuf), "%lu years ago", (diff + 183) / 365);
+		return timebuf;

I agree this is an improvement.  It irritated me, too.  And I do not think
this change falls into the category of bad backward incompatibility.

I was hoping somebody would do a "N years M months", though.

I thought about that, but I wanted to keep the maximum size down for
column output (like in git-blame). Which is why I bumped the "use
months" limit to 24 months instead of 12.

And that limit can also be tweaked.  Surely at some point there is a
range where you no longer care about the months and "N years" has high
enough resolution. But there is also a point where "N months" gets
cumbersome (75 months is a more annoying than "around 6 years"). The
question is whether we reach the "cumbersome" point before we reach the
"don't care about months" point.

Another option would to give higher resolution in number of years, like
"3.5 years" or even "3.1 years".

-Peff

Jeff King said the following on 23.02.2009 04:16:

On Sun, Feb 22, 2009 at 05:44:37PM -0800, Junio C Hamano wrote:

quoted

quoted

+		/* Otherwise, years. Centuries is probably overkill. */
+		snprintf(timebuf, sizeof(timebuf), "%lu years ago", (diff + 183) / 365);
+		return timebuf;

I agree this is an improvement.  It irritated me, too.  And I do
not think this change falls into the category of bad backward
incompatibility.

I was hoping somebody would do a "N years M months", though.

I thought about that, but I wanted to keep the maximum size down
for column output (like in git-blame). Which is why I bumped the
"use months" limit to 24 months instead of 12.

And that limit can also be tweaked.  Surely at some point there is
a range where you no longer care about the months and "N years" has
high enough resolution. But there is also a point where "N months"
gets cumbersome (75 months is a more annoying than "around 6
years"). The question is whether we reach the "cumbersome" point
before we reach the "don't care about months" point.

Another option would to give higher resolution in number of years,
like "3.5 years" or even "3.1 years".

And using shorter names for the units would be a no-go?

   "3y 2m ago"    <--
   "3 years ago"
   "3 months ago"
   "3 weeks ago"
   "3 days ago"
   "3 hours ago"
   "3 mins ago"   <--
   "3 secs ago"   <--

-- 
.marius [@trolltech.com]
'if you know what you're doing, it's not research'

Jeff King [off-list ref] writes:

I thought about that, but I wanted to keep the maximum size down for
column output (like in git-blame). Which is why I bumped the "use
months" limit to 24 months instead of 12.

And that limit can also be tweaked.  Surely at some point there is a
range where you no longer care about the months and "N years" has high
enough resolution. But there is also a point where "N months" gets
cumbersome (75 months is a more annoying than "around 6 years"). The
question is whether we reach the "cumbersome" point before we reach the
"don't care about months" point.

Yes, "75 months" is unacceptable.  I suspect people's mind would not work
well with anything larger than 60 months.  I've actually thought about
"don't care about months" point, but 12 months is a long time.  You
certainly remember there still was a noticeable maturity difference
between classmates who were born in the earliest months of the school year
and in the last months before graduating grade school.  Perhaps after 20
years.

Another option would to give higher resolution in number of years, like
"3.5 years" or even "3.1 years".

But I do not think people think of years in terms of decimal fraction.

On Mon, Feb 23, 2009 at 09:09:02AM +0100, Marius Storm-Olsen wrote:

quoted

Another option would to give higher resolution in number of years,
like "3.5 years" or even "3.1 years".

And using shorter names for the units would be a no-go?

  "3y 2m ago"    <--

Personally I think that looks terrible. But I recognize that it is
very subjective. The only objective thing I can say is that "m" is not a
unique prefix of a time unit, due to "minutes". Yes, it is obvious if
you see the "y" first, but I actually parse the relative time backwards
in my head and think "2 minutes ago, oh wait, 3 years, that must be
months".

-Peff

On Mon, Feb 23, 2009 at 08:33:37AM -0800, Junio C Hamano wrote:

Yes, "75 months" is unacceptable.  I suspect people's mind would not work
well with anything larger than 60 months.  I've actually thought about
"don't care about months" point, but 12 months is a long time.  You
certainly remember there still was a noticeable maturity difference
between classmates who were born in the earliest months of the school year
and in the last months before graduating grade school.  Perhaps after 20
years.

I'm not sure human and code development necessarily follow the same
timelines. Git wouldn't even be in kindergarten yet. ;)

quoted

Another option would to give higher resolution in number of years, like
"3.5 years" or even "3.1 years".

But I do not think people think of years in terms of decimal fraction.

I think decimal fraction is overkill. Halves or quarters are more
reasonable.

But after sleeping on it, I think "Y years, M months" is not that bad.
So here is a patch (Eugene, note that this conflicts with your "fall
back to DATE_SHORT" patch).

-- >8 --
Subject: [PATCH] never fallback relative times to absolute

Previously, for dates older than 12 months we fell back to
just giving the absolute time. This can be a bit jarring
when reading a list of times. Instead, let's switch to "Y
years, M months" for five years, and then just "Y years"
after that.

No particular reason on the 5 year cutoff except that it
seemed reasonable to me.

Signed-off-by: Jeff King <redacted>
---
Please feel free to mark the 5 years up to 20, or whatever
you think is appropriate.

I think this should produce good output in all cases. There
are a surprising number of corner cases, and I spent an
embarrassing amount of time looking at the output of "git
log --pretty=tformat:'%ai / %ar'".

You could also argue for splitting this into "support N
years, M months" and then still fall back to absolute time
eventually (whether DATE_SHORT or not).

 date.c |   20 +++++++++++++++++++-
 1 files changed, 19 insertions(+), 1 deletions(-)

diff --git a/date.c b/date.c
index d75dff4..1165d30 100644
--- a/date.c
+++ b/date.c

@@ -133,7 +133,25 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)
 			snprintf(timebuf, sizeof(timebuf), "%lu months ago", (diff + 15) / 30);
 			return timebuf;
 		}
-		/* Else fall back on absolute format.. */
+		/* Give years and months for 5 years or so */
+		if (diff < 1825) {
+			unsigned long years = (diff + 183) / 365;
+			unsigned long months = (diff % 365 + 15) / 30;
+			int n;
+			n = snprintf(timebuf, sizeof(timebuf), "%lu year%s",
+					years, (years > 1 ? "s" : ""));
+			if (months)
+				snprintf(timebuf + n, sizeof(timebuf) - n,
+					", %lu month%s ago",
+					months, (months > 1 ? "s" : ""));
+			else
+				snprintf(timebuf + n, sizeof(timebuf) - n,
+					" ago");
+			return timebuf;
+		}
+		/* Otherwise, just years. Centuries is probably overkill. */
+		snprintf(timebuf, sizeof(timebuf), "%lu years ago", (diff + 183) / 365);
+		return timebuf;
 	}
 
 	if (mode == DATE_LOCAL)

-- 
1.6.2.rc1.269.ga7d41

Jeff King said the following on 24.02.2009 06:04:

On Mon, Feb 23, 2009 at 09:09:02AM +0100, Marius Storm-Olsen wrote:

quoted

quoted

Another option would to give higher resolution in number of
years, like "3.5 years" or even "3.1 years".

And using shorter names for the units would be a no-go?

"3y 2m ago"    <--

Personally I think that looks terrible. But I recognize that it is 
very subjective. The only objective thing I can say is that "m" is
not a unique prefix of a time unit, due to "minutes". Yes, it is
obvious if you see the "y" first, but I actually parse the relative
time backwards in my head and think "2 minutes ago, oh wait, 3
years, that must be months".

Ok, the standard abbreviation for month is "mo.", so

   "3y 2mo. ago"

then? ;-)

-- 
.marius [@trolltech.com]
'if you know what you're doing, it's not research'

On Tue, Feb 24, 2009 at 07:35:05AM +0100, Marius Storm-Olsen wrote:

Ok, the standard abbreviation for month is "mo.", so

  "3y 2mo. ago"

then? ;-)

That is definitely better, but see the patch I just posted elsewhere in
the thread.

-Peff