From: Junio C Hamano <hidden> Date: 2016-06-15 22:47:20
Alex Riesen [off-list ref] writes:
To complement the testability of approxidate.
---
Alex Riesen, Fri, Aug 28, 2009 21:33:02 +0200:
quoted
It should allow safe testing of this part of the code.
And this should really allow testing of it:
$ ./test-date '10.days.ago'
10.days.ago -> bad -> Thu Jan 1 01:00:00 1970
10.days.ago -> Tue Aug 18 22:50:20 2009
relative: 10.days.ago -> Fri Dec 22 12:00:00 1989
relative: 10 days ago, out of Fri Dec 22 12:00:00 1989
$
What are these blank lines for? Is this intended as a serious submission
for inclusion? I am having a hrad time to guess, especially you did not
sign this off, nor Cc'ed me.
From: Alex Riesen <hidden> Date: 2016-06-15 22:47:20
On Sat, Aug 29, 2009 at 23:46, Junio C Hamano[off-list ref] wrote:
Alex Riesen [off-list ref] writes:
quoted
To complement the testability of approxidate.
---
Alex Riesen, Fri, Aug 28, 2009 21:33:02 +0200:
quoted
It should allow safe testing of this part of the code.
And this should really allow testing of it:
$ ./test-date '10.days.ago'
10.days.ago -> bad -> Thu Jan 1 01:00:00 1970
10.days.ago -> Tue Aug 18 22:50:20 2009
relative: 10.days.ago -> Fri Dec 22 12:00:00 1989
relative: 10 days ago, out of Fri Dec 22 12:00:00 1989
$
What are these blank lines for?
ctime(3) artifact (it adds a \n in the output buffer), which I missed.
Is this intended as a serious submission for inclusion?
Not yet. AFAICS, test-date is never used in our test suite.
I am having a hrad time to guess, especially you did not
sign this off, nor Cc'ed me.
Right, that's because I'm not sure myself. Frankly, I'm not
convinced we have to test every single thing. In my experience,
the bigger a test suite, the less are people inclined to use it
(including setting up automatic test runs).
Jeff, Nicolas? Is this test enough? Are there any other code
paths you want to include in the test?
And sorry for having you missed in Cc:, that wasn't intended.
From: Jeff King <hidden> Date: 2016-06-15 22:47:20
On Sun, Aug 30, 2009 at 09:25:11AM +0200, Alex Riesen wrote:
quoted
Is this intended as a serious submission for inclusion?
Not yet. AFAICS, test-date is never used in our test suite.
No, it isn't, but I think the point of this is to change that.
So it is useless without an extra patch to the test suite. I'll try to
put something together.
Right, that's because I'm not sure myself. Frankly, I'm not
convinced we have to test every single thing. In my experience,
the bigger a test suite, the less are people inclined to use it
(including setting up automatic test runs).
Jeff, Nicolas? Is this test enough? Are there any other code
paths you want to include in the test?
I think this is a useful addition to the test suite. The bug David fixed
was obvious, but it sat for a year because of poor test coverage. Linus
fixed several approxidate bugs recently. The approxidate code is
notoriously temperamental, so it is a good thing to be checking for
regressions.
And I don't think our test suite is nearly big enough to start worrying
about getting people not to use it. Without CVS and SVN tests, I can run
it on 3-year-old hardware in less than a minute. Either you bother to
run it or not, but I doubt that adding one new test script is going to
break the bank.
-Peff
From: Alex Riesen <hidden> Date: 2016-06-15 22:47:20
On Sun, Aug 30, 2009 at 09:51, Jeff King[off-list ref] wrote:
On Sun, Aug 30, 2009 at 09:25:11AM +0200, Alex Riesen wrote:
quoted
quoted
Is this intended as a serious submission for inclusion?
Not yet. AFAICS, test-date is never used in our test suite.
No, it isn't, but I think the point of this is to change that.
So it is useless without an extra patch to the test suite. I'll try to
put something together.
@@ -4,6 +4,19 @@ int main(int argc, char **argv){inti;+/* see date.c, function show_date_relative */+chartimebuf[(sizeof(long)*5/2+sizeof(" minutes ago,"))*2];+structtmtm;+structtimevalwhen={0,0};+tm.tm_sec=0;+tm.tm_min=0;+tm.tm_hour=12;+tm.tm_mday=1;+tm.tm_mon=0/* January */;+tm.tm_year=90/* 1990 */;+tm.tm_isdst=-1;+when.tv_sec=mktime(&tm);+for(i=1;i<argc;i++){charresult[100];time_tt;
@@ -15,6 +28,13 @@ int main(int argc, char **argv)t=approxidate(argv[i]);printf("%s -> %s\n",argv[i],ctime(&t));++t=approxidate_relative(argv[i],&when);+printf("relative: %s -> %s",argv[i],ctime(&t));++printf("relative: %s, out of %s",+show_date_relative(t,0,&when,timebuf,sizeof(timebuf)),+ctime(&t));}return0;}
From: Alex Riesen <hidden> Date: 2016-06-15 22:47:20
The main purpose is to allow predictable testing of the code.
Signed-off-by: Alex Riesen <redacted>
---
Have show_date_relative supplied the output buffer. As it is a new
interface, it can as well be a little bit more generic than its sole
caller. test-date.c is updated and shall follow in a moment.
And, after a while thinking, I am convinced that Jeff has a point
and used a more "internal" name for approxidate's recent "bottom half".
cache.h | 5 ++
date.c | 152 +++++++++++++++++++++++++++++++++++++--------------------------
2 files changed, 94 insertions(+), 63 deletions(-)
@@ -84,6 +84,68 @@ static int local_tzoffset(unsigned long time)returnoffset*eastwest;}+constchar*show_date_relative(unsignedlongtime,inttz,+conststructtimeval*now,+char*timebuf,+size_ttimebuf_size)+{+unsignedlongdiff;+if(now->tv_sec<time)+return"in the future";+diff=now->tv_sec-time;+if(diff<90){+snprintf(timebuf,timebuf_size,"%lu seconds ago",diff);+returntimebuf;+}+/* Turn it into minutes */+diff=(diff+30)/60;+if(diff<90){+snprintf(timebuf,timebuf_size,"%lu minutes ago",diff);+returntimebuf;+}+/* Turn it into hours */+diff=(diff+30)/60;+if(diff<36){+snprintf(timebuf,timebuf_size,"%lu hours ago",diff);+returntimebuf;+}+/* We deal with number of days from here on */+diff=(diff+12)/24;+if(diff<14){+snprintf(timebuf,timebuf_size,"%lu days ago",diff);+returntimebuf;+}+/* Say weeks for the past 10 weeks or so */+if(diff<70){+snprintf(timebuf,timebuf_size,"%lu weeks ago",(diff+3)/7);+returntimebuf;+}+/* Say months for the past 12 months or so */+if(diff<360){+snprintf(timebuf,timebuf_size,"%lu months ago",(diff+15)/30);+returntimebuf;+}+/* Give years and months for 5 years or so */+if(diff<1825){+unsignedlongyears=diff/365;+unsignedlongmonths=(diff%365+15)/30;+intn;+n=snprintf(timebuf,timebuf_size,"%lu year%s",+years,(years>1?"s":""));+if(months)+snprintf(timebuf+n,timebuf_size-n,+", %lu month%s ago",+months,(months>1?"s":""));+else+snprintf(timebuf+n,timebuf_size-n,+" ago");+returntimebuf;+}+/* Otherwise, just years. Centuries is probably overkill. */+snprintf(timebuf,timebuf_size,"%lu years ago",(diff+183)/365);+returntimebuf;+}+constchar*show_date(unsignedlongtime,inttz,enumdate_modemode){structtm*tm;
@@ -95,63 +157,10 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)}if(mode==DATE_RELATIVE){-unsignedlongdiff;structtimevalnow;gettimeofday(&now,NULL);-if(now.tv_sec<time)-return"in the future";-diff=now.tv_sec-time;-if(diff<90){-snprintf(timebuf,sizeof(timebuf),"%lu seconds ago",diff);-returntimebuf;-}-/* Turn it into minutes */-diff=(diff+30)/60;-if(diff<90){-snprintf(timebuf,sizeof(timebuf),"%lu minutes ago",diff);-returntimebuf;-}-/* Turn it into hours */-diff=(diff+30)/60;-if(diff<36){-snprintf(timebuf,sizeof(timebuf),"%lu hours ago",diff);-returntimebuf;-}-/* We deal with number of days from here on */-diff=(diff+12)/24;-if(diff<14){-snprintf(timebuf,sizeof(timebuf),"%lu days ago",diff);-returntimebuf;-}-/* Say weeks for the past 10 weeks or so */-if(diff<70){-snprintf(timebuf,sizeof(timebuf),"%lu weeks ago",(diff+3)/7);-returntimebuf;-}-/* Say months for the past 12 months or so */-if(diff<360){-snprintf(timebuf,sizeof(timebuf),"%lu months ago",(diff+15)/30);-returntimebuf;-}-/* Give years and months for 5 years or so */-if(diff<1825){-unsignedlongyears=diff/365;-unsignedlongmonths=(diff%365+15)/30;-intn;-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");-returntimebuf;-}-/* Otherwise, just years. Centuries is probably overkill. */-snprintf(timebuf,sizeof(timebuf),"%lu years ago",(diff+183)/365);-returntimebuf;+returnshow_date_relative(time,tz,&now,+timebuf,sizeof(timebuf));}if(mode==DATE_LOCAL)
From: Jeff King <hidden> Date: 2016-06-15 22:47:20
On Sun, Aug 30, 2009 at 11:13:46AM +0200, Alex Riesen wrote:
Have show_date_relative supplied the output buffer. As it is a new
interface, it can as well be a little bit more generic than its sole
caller. test-date.c is updated and shall follow in a moment.
FYI, I am munging test-date to match the test script I am writing, so
don't bother with that patch.
-Peff
From: Jeff King <hidden> Date: 2016-06-15 22:47:20
On Sun, Aug 30, 2009 at 05:15:57AM -0400, Jeff King wrote:
FYI, I am munging test-date to match the test script I am writing, so
don't bother with that patch.
Here is what my patch is looking like. Please give any comments, and
then I will resubmit in a form that will be simpler for Junio, which
should be a series with:
- your patch to refactor date.c
- this patch (this version uses the original interface to
show_relative; I will tweak to match the new patch you just sent)
- another patch to go on top of lt/approxidate to test recent fixes
from Linus
---
From: Alex Riesen <hidden> Date: 2016-06-15 22:47:20
On Sun, Aug 30, 2009 at 11:36, Jeff King[off-list ref] wrote:
On Sun, Aug 30, 2009 at 05:15:57AM -0400, Jeff King wrote:
quoted
FYI, I am munging test-date to match the test script I am writing, so
don't bother with that patch.
Here is what my patch is looking like. Please give any comments, and
then I will resubmit in a form that will be simpler for Junio, which
should be a series with:
- your patch to refactor date.c
- this patch (this version uses the original interface to
show_relative; I will tweak to match the new patch you just sent)
Yes, I think this is the only comment I can make.
+# arbitrary reference time: 2009-08-30 19:20:00
The world changed since 1980 :) There is already three things
happened at the day (http://en.wikipedia.org/wiki/August_2009),
and it is not evening yet (well, here in Europe)
check_show 630000000 '20.years.ago'?
(Arbitrary, non-whitespace delimiters, which was an
advertised feature, to make shell's life easier)
This part is about checking what show_date produces (the first number is
an offset from now in seconds, and the second is what we expect), so it
always has spaces.
See the check_approxidate section further down for an example of parsing
what you are talking about.
-Peff
From: Alex Riesen <hidden> Date: 2016-06-15 22:47:20
On Sun, Aug 30, 2009 at 12:08, Jeff King[off-list ref] wrote:
On Sun, Aug 30, 2009 at 11:56:37AM +0200, Alex Riesen wrote:
quoted
check_show 630000000 '20.years.ago'?
(Arbitrary, non-whitespace delimiters, which was an
advertised feature, to make shell's life easier)
This part is about checking what show_date produces (the first number is
an offset from now in seconds, and the second is what we expect), so it
always has spaces.
See the check_approxidate section further down for an example of parsing
what you are talking about.
From: Jeff King <hidden> Date: 2016-06-15 22:47:20
From: Alex Riesen <redacted>
The main purpose is to allow predictable testing of the code.
Signed-off-by: Alex Riesen <redacted>
Signed-off-by: Jeff King <redacted>
---
cache.h | 5 ++
date.c | 152 +++++++++++++++++++++++++++++++++++++--------------------------
2 files changed, 94 insertions(+), 63 deletions(-)
@@ -84,6 +84,68 @@ static int local_tzoffset(unsigned long time)returnoffset*eastwest;}+constchar*show_date_relative(unsignedlongtime,inttz,+conststructtimeval*now,+char*timebuf,+size_ttimebuf_size)+{+unsignedlongdiff;+if(now->tv_sec<time)+return"in the future";+diff=now->tv_sec-time;+if(diff<90){+snprintf(timebuf,timebuf_size,"%lu seconds ago",diff);+returntimebuf;+}+/* Turn it into minutes */+diff=(diff+30)/60;+if(diff<90){+snprintf(timebuf,timebuf_size,"%lu minutes ago",diff);+returntimebuf;+}+/* Turn it into hours */+diff=(diff+30)/60;+if(diff<36){+snprintf(timebuf,timebuf_size,"%lu hours ago",diff);+returntimebuf;+}+/* We deal with number of days from here on */+diff=(diff+12)/24;+if(diff<14){+snprintf(timebuf,timebuf_size,"%lu days ago",diff);+returntimebuf;+}+/* Say weeks for the past 10 weeks or so */+if(diff<70){+snprintf(timebuf,timebuf_size,"%lu weeks ago",(diff+3)/7);+returntimebuf;+}+/* Say months for the past 12 months or so */+if(diff<360){+snprintf(timebuf,timebuf_size,"%lu months ago",(diff+15)/30);+returntimebuf;+}+/* Give years and months for 5 years or so */+if(diff<1825){+unsignedlongyears=diff/365;+unsignedlongmonths=(diff%365+15)/30;+intn;+n=snprintf(timebuf,timebuf_size,"%lu year%s",+years,(years>1?"s":""));+if(months)+snprintf(timebuf+n,timebuf_size-n,+", %lu month%s ago",+months,(months>1?"s":""));+else+snprintf(timebuf+n,timebuf_size-n,+" ago");+returntimebuf;+}+/* Otherwise, just years. Centuries is probably overkill. */+snprintf(timebuf,timebuf_size,"%lu years ago",(diff+183)/365);+returntimebuf;+}+constchar*show_date(unsignedlongtime,inttz,enumdate_modemode){structtm*tm;
@@ -95,63 +157,10 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)}if(mode==DATE_RELATIVE){-unsignedlongdiff;structtimevalnow;gettimeofday(&now,NULL);-if(now.tv_sec<time)-return"in the future";-diff=now.tv_sec-time;-if(diff<90){-snprintf(timebuf,sizeof(timebuf),"%lu seconds ago",diff);-returntimebuf;-}-/* Turn it into minutes */-diff=(diff+30)/60;-if(diff<90){-snprintf(timebuf,sizeof(timebuf),"%lu minutes ago",diff);-returntimebuf;-}-/* Turn it into hours */-diff=(diff+30)/60;-if(diff<36){-snprintf(timebuf,sizeof(timebuf),"%lu hours ago",diff);-returntimebuf;-}-/* We deal with number of days from here on */-diff=(diff+12)/24;-if(diff<14){-snprintf(timebuf,sizeof(timebuf),"%lu days ago",diff);-returntimebuf;-}-/* Say weeks for the past 10 weeks or so */-if(diff<70){-snprintf(timebuf,sizeof(timebuf),"%lu weeks ago",(diff+3)/7);-returntimebuf;-}-/* Say months for the past 12 months or so */-if(diff<360){-snprintf(timebuf,sizeof(timebuf),"%lu months ago",(diff+15)/30);-returntimebuf;-}-/* Give years and months for 5 years or so */-if(diff<1825){-unsignedlongyears=diff/365;-unsignedlongmonths=(diff%365+15)/30;-intn;-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");-returntimebuf;-}-/* Otherwise, just years. Centuries is probably overkill. */-snprintf(timebuf,sizeof(timebuf),"%lu years ago",(diff+183)/365);-returntimebuf;+returnshow_date_relative(time,tz,&now,+timebuf,sizeof(timebuf));}if(mode==DATE_LOCAL)
From: Jeff King <hidden> Date: 2016-06-15 22:47:20
The test-date program goes back to the early days of git,
where it was presumably used to do manual sanity checks on
changes to the date code. However, it is not actually used
by the test suite to do any sort of automatic of systematic
tests.
This patch refactors the interface to the program to try to
make it more suitable for use by the test suite. There
should be no fallouts to changing the interface since it is
not actually installed and is not internally called by any
other programs.
The changes are:
- add a "mode" parameter so the caller can specify which
operation to test
- add a mode to test relative date output from show_date
- allow faking a fixed time via the TEST_DATE_NOW
environment variable, which allows consistent automated
testing
- drop the use of ctime for showing dates in favor of our
internal iso8601 printing routines. The ctime output is
somewhat redundant (because of the day-of-week) which
makes writing test cases more annoying.
Signed-off-by: Jeff King <redacted>
---
I mulled over replacing ctime for a bit, as we are testing git's date
code with other parts of git's date code. But it really is more
convenient for writing test cases to use iso8601, since you don't have
to calculate the day-of-week (and I also think it is a bit more
readable). And our iso8601 code is dead simple, so I am not too worried
about a bug in it hiding a bug elsewhere.
test-date.c | 86 +++++++++++++++++++++++++++++++++++++++++++++-------------
1 files changed, 66 insertions(+), 20 deletions(-)
rewrite test-date.c (63%)
diff --git a/test-date.c b/test-date.cdissimilarity index 63%index 62e8f23..5b0a220 100644--- a/test-date.c+++ b/test-date.c
From: Jeff King <hidden> Date: 2016-06-15 22:47:20
Until now, there was no coverage of relative date printing
or approxidate parsing routines (mainly because we had no
way of faking the "now" time for relative date calculations,
which made consistent testing impossible).
This new script tries to exercise the basic features of
show_date and approxidate. The only specific problem case
tested is showing relative year/month dates in the latter
half of a year, as fixed by 607a9e8.
Signed-off-by: Jeff King <redacted>
---
Like I said, this is really just to exercise the basic code paths.
But now that the infrastructure is there, we can add any corner cases
or verify new features or bug fixes as they come up. Patches welcome. :)
t/t0006-date.sh | 71 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 71 insertions(+), 0 deletions(-)
create mode 100755 t/t0006-date.sh
From: Jeff King <hidden> Date: 2016-06-15 22:47:20
On Sun, Aug 30, 2009 at 05:43:09PM -0400, Jeff King wrote:
From: Alex Riesen <redacted>
The main purpose is to allow predictable testing of the code.
Signed-off-by: Alex Riesen <redacted>
Signed-off-by: Jeff King <redacted>
---
Bleh. I just started working on a 4/3 that would test Linus' recent
approxidate changes, but then I realized that this massive date.c
refactoring conflicts with his changes.
I think the most sane thing is to rebase the whole series on top of
lt/approxidate. Let me see what I can do.
-Peff
From: Jeff King <hidden> Date: 2016-06-15 22:47:20
On Sun, Aug 30, 2009 at 05:51:27PM -0400, Jeff King wrote:
I think the most sane thing is to rebase the whole series on top of
lt/approxidate. Let me see what I can do.
And here it is. It was a little more complex than a simple rebase
because lt/approxidate actually introduced new bugs. :) Hopefully this
will be the last re-roll required.
The new series applies on top of lt/approxidate, and contains:
[1/4]: Add date formatting and parsing functions relative to a given time
[2/4]: refactor test-date interface
[3/4]: tests: add date printing and parsing tests
[4/4]: fix approxidate parsing of relative months and years
-Peff
From: Jeff King <hidden> Date: 2016-06-15 22:47:20
From: Alex Riesen <redacted>
The main purpose is to allow predictable testing of the code.
Signed-off-by: Alex Riesen <redacted>
Signed-off-by: Jeff King <redacted>
---
Same as previous 1/3, but rebased onto lt/approxidate topic. The merge
ended up as quite a mess because of textual differences, so I had to
fix up a fair bit by hand; Alex, please confirm that I didn't screw
anything up too badly right before putting your name at the top. ;)
cache.h | 5 ++
date.c | 150 ++++++++++++++++++++++++++++++++++++--------------------------
2 files changed, 92 insertions(+), 63 deletions(-)
@@ -86,6 +86,67 @@ static int local_tzoffset(unsigned long time)returnoffset*eastwest;}+constchar*show_date_relative(unsignedlongtime,inttz,+conststructtimeval*now,+char*timebuf,+size_ttimebuf_size)+{+unsignedlongdiff;+if(now->tv_sec<time)+return"in the future";+diff=now->tv_sec-time;+if(diff<90){+snprintf(timebuf,timebuf_size,"%lu seconds ago",diff);+returntimebuf;+}+/* Turn it into minutes */+diff=(diff+30)/60;+if(diff<90){+snprintf(timebuf,timebuf_size,"%lu minutes ago",diff);+returntimebuf;+}+/* Turn it into hours */+diff=(diff+30)/60;+if(diff<36){+snprintf(timebuf,timebuf_size,"%lu hours ago",diff);+returntimebuf;+}+/* We deal with number of days from here on */+diff=(diff+12)/24;+if(diff<14){+snprintf(timebuf,timebuf_size,"%lu days ago",diff);+returntimebuf;+}+/* Say weeks for the past 10 weeks or so */+if(diff<70){+snprintf(timebuf,timebuf_size,"%lu weeks ago",(diff+3)/7);+returntimebuf;+}+/* Say months for the past 12 months or so */+if(diff<360){+snprintf(timebuf,timebuf_size,"%lu months ago",(diff+15)/30);+returntimebuf;+}+/* Give years and months for 5 years or so */+if(diff<1825){+unsignedlongyears=diff/365;+unsignedlongmonths=(diff%365+15)/30;+intn;+n=snprintf(timebuf,timebuf_size,"%lu year%s",+years,(years>1?"s":""));+if(months)+snprintf(timebuf+n,timebuf_size-n,+", %lu month%s ago",+months,(months>1?"s":""));+else+snprintf(timebuf+n,timebuf_size-n," ago");+returntimebuf;+}+/* Otherwise, just years. Centuries is probably overkill. */+snprintf(timebuf,timebuf_size,"%lu years ago",(diff+183)/365);+returntimebuf;+}+constchar*show_date(unsignedlongtime,inttz,enumdate_modemode){structtm*tm;
@@ -97,63 +158,10 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)}if(mode==DATE_RELATIVE){-unsignedlongdiff;structtimevalnow;gettimeofday(&now,NULL);-if(now.tv_sec<time)-return"in the future";-diff=now.tv_sec-time;-if(diff<90){-snprintf(timebuf,sizeof(timebuf),"%lu seconds ago",diff);-returntimebuf;-}-/* Turn it into minutes */-diff=(diff+30)/60;-if(diff<90){-snprintf(timebuf,sizeof(timebuf),"%lu minutes ago",diff);-returntimebuf;-}-/* Turn it into hours */-diff=(diff+30)/60;-if(diff<36){-snprintf(timebuf,sizeof(timebuf),"%lu hours ago",diff);-returntimebuf;-}-/* We deal with number of days from here on */-diff=(diff+12)/24;-if(diff<14){-snprintf(timebuf,sizeof(timebuf),"%lu days ago",diff);-returntimebuf;-}-/* Say weeks for the past 10 weeks or so */-if(diff<70){-snprintf(timebuf,sizeof(timebuf),"%lu weeks ago",(diff+3)/7);-returntimebuf;-}-/* Say months for the past 12 months or so */-if(diff<360){-snprintf(timebuf,sizeof(timebuf),"%lu months ago",(diff+15)/30);-returntimebuf;-}-/* Give years and months for 5 years or so */-if(diff<1825){-unsignedlongyears=diff/365;-unsignedlongmonths=(diff%365+15)/30;-intn;-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");-returntimebuf;-}-/* Otherwise, just years. Centuries is probably overkill. */-snprintf(timebuf,sizeof(timebuf),"%lu years ago",(diff+183)/365);-returntimebuf;+returnshow_date_relative(time,tz,&now,+timebuf,sizeof(timebuf));}if(mode==DATE_LOCAL)
From: Jeff King <hidden> Date: 2016-06-15 22:47:20
The test-date program goes back to the early days of git,
where it was presumably used to do manual sanity checks on
changes to the date code. However, it is not actually used
by the test suite to do any sort of automatic of systematic
tests.
This patch refactors the interface to the program to try to
make it more suitable for use by the test suite. There
should be no fallouts to changing the interface since it is
not actually installed and is not internally called by any
other programs.
The changes are:
- add a "mode" parameter so the caller can specify which
operation to test
- add a mode to test relative date output from show_date
- allow faking a fixed time via the TEST_DATE_NOW
environment variable, which allows consistent automated
testing
- drop the use of ctime for showing dates in favor of our
internal iso8601 printing routines. The ctime output is
somewhat redundant (because of the day-of-week) which
makes writing test cases more annoying.
Signed-off-by: Jeff King <redacted>
---
Same as earlier 2/3.
test-date.c | 86 +++++++++++++++++++++++++++++++++++++++++++++-------------
1 files changed, 66 insertions(+), 20 deletions(-)
rewrite test-date.c (63%)
diff --git a/test-date.c b/test-date.cdissimilarity index 63%index 62e8f23..5b0a220 100644--- a/test-date.c+++ b/test-date.c
From: Jeff King <hidden> Date: 2016-06-15 22:47:20
Until now, there was no coverage of relative date printing
or approxidate parsing routines (mainly because we had no
way of faking the "now" time for relative date calculations,
which made consistent testing impossible).
This new script tries to exercise the basic features of
show_date and approxidate. Most of the tests are just "this
obvious thing works" to prevent future regressions, with a
few exceptions:
- We confirm the fix in 607a9e8 that relative year/month
dates in the latter half of a year round correctly.
- We confirm that the improvements in b5373e9 and 1bddb25
work.
- A few tests are marked to expect failure, which are
regressions recently introduced by the two commits
above.
Signed-off-by: Jeff King <redacted>
---
Similar to earlier 3/3, but improvements and regressions from
lt/approxidate included.
Linus, when you posted the approxidate fixes earlier, you mentioned you
might have some other corner cases. I think you were just referring to
the stuff you improved in the followup patch, but if you know of more
broken-ness, we should probably include it here.
t/t0006-date.sh | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 75 insertions(+), 0 deletions(-)
create mode 100755 t/t0006-date.sh
From: Jeff King <hidden> Date: 2016-06-15 22:47:20
These were broken by b5373e9. The problem is that the code
marks the month and year with "-1" for "we don't know it
yet", but the month and year code paths were not adjusted to
fill in the current time before doing their calculations
(whereas other units follow a different code path and are
fine).
Signed-off-by: Jeff King <redacted>
---
This one is new from the last series, as it fixes bugs only found in
lt/approxidate.
date.c | 5 ++++-
t/t0006-date.sh | 4 ++--
2 files changed, 6 insertions(+), 3 deletions(-)
From: Alex Riesen <hidden> Date: 2016-06-15 22:47:20
On Mon, Aug 31, 2009 at 04:26, Jeff King[off-list ref] wrote:
From: Alex Riesen <redacted>
The main purpose is to allow predictable testing of the code.
Signed-off-by: Alex Riesen <redacted>
Signed-off-by: Jeff King <redacted>
---
Same as previous 1/3, but rebased onto lt/approxidate topic. The merge
ended up as quite a mess because of textual differences, so I had to
fix up a fair bit by hand; Alex, please confirm that I didn't screw
anything up too badly right before putting your name at the top. ;)
From: Jeff King <hidden> Date: 2016-06-15 22:47:20
On Sun, Aug 30, 2009 at 10:30:15PM -0400, Jeff King wrote:
- We confirm that the improvements in b5373e9 and 1bddb25
work.
Ugh. I just realized (when explaining how awesome git resurrect was in
another mail) that I managed to bungle these commit hashes (and the one
mentioned in the following patch).
What happened is that I was building on the topic branch and lazily did
a "rebase -i origin" to fix up my patches. I left the first two patches
untouched, of course, but they still ended up with new committer
information.
As my patches are merged to 'next' already, I think it is too late to
fixup the commit message. But for posterity, the correct referenced
commits are 9029055 and 36e4986.
Caveat rebaser.
-Peff