Thread (8 messages) flat view 8 messages, 3 authors, 2016-06-15

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

From: Jeff King <hidden>
Date: 2016-06-15 22:46:16
Subsystem: the rest · Maintainer: Linus Torvalds

Possibly related (same subject, not in this thread)

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help