Git development
 help / color / mirror / Atom feed
From: Tuomas Ahola <taahol@utu.fi>
To: <git@vger.kernel.org>
Cc: Jeff King <peff@peff.net>, Junio C Hamano <gitster@pobox.com>,
	Tuomas Ahola <taahol@utu.fi>
Subject: [PATCH v3 1/4] t0006: add support for approxidate test date adjustment
Date: Thu, 14 May 2026 14:55:17 +0300	[thread overview]
Message-ID: <20260514115520.6660-2-taahol@utu.fi> (raw)
In-Reply-To: <20260514115520.6660-1-taahol@utu.fi>

t0006 uses a hard-coded test date and provides no convenient
way to override it temporarily.  Add an optional parameter to
check_approxidate to adjust the time as needed, and demonstrate
the feature with a new test.

Signed-off-by: Tuomas Ahola <taahol@utu.fi>
---

Notes:
    > As you are not doing the test-date-now adjustment when $4 is not
    > given, wouldn't it be a lot easier to read if you did something like
    >
    > 	old_date=$GIT_TEST_DATE_NOW
    > 	if test -n "$4"
    > 	then
    > 		# the convention for $4 is a bit weird in that it
    > 		# comes with its own +/- operator in front.
    > 		GIT_TEST_DATE_NOW=$(( $old_date $4 * 60 * 60 ))
    > 		caption="$1; offset $4h"
    > 	else
    >         	caption=$1
    > 	fi
    >
    > instead?  Other two minor points are
    >
    >  - Documentation/SubmittingPatches prefers an explicit "test" over
    >    "[ ... ]", and have "then", "else", etc. on their own lines.
    >
    >  - As you never "unset" GIT_TEST_DATE_NOW, you do not have to keep
    >    exporting it.  It is not like there are two variables (one for
    >    shell, the other for environment) and every time you set the
    >    shell one you need to export to reflect the value to the
    >    environment one.  Rather, a single "export" marks a shell
    >    variable and every time it changes value, it is updated in the
    >    environment as well.
    >
    
    Thanks, applied.
    
    > One, it sucks to have to say "success" here, but is awkward because now
    > we have two optional arguments. There's nobody passing "failure" right
    > now, so we could just drop support, though that might be annoying later
    > when somebody wants to add a failing test. But we could perhaps switch
    > to allowing:
    >
    
    Ok, now it works without "success" in between, and "failure" works without
    an offset, too.
    
    	check_approxidate <test-string> <expected-result> [<test-time-offset>] [failure]
    
    > The second thing is that "+48" is pretty opaque. It's a relative offset
    > to some arbitrary point. To some degree the script already suffers from
    > that (all of the tests are using some arbitrary point), but I think the
    > offset (without units!) adds a layer of indirection that makes it even
    > more confusing.
    >
    
    Good catch.  Now it is at least marginally better with the added units.

 t/t0006-date.sh | 33 ++++++++++++++++++++++++++++++++-
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/t/t0006-date.sh b/t/t0006-date.sh
index 53ced36df4..c7667bade2 100755
--- a/t/t0006-date.sh
+++ b/t/t0006-date.sh
@@ -155,12 +155,41 @@ check_parse '2100-00-00 00:00:00 -11' bad
 check_parse '2100-00-00 00:00:00 +11' bad
 REQUIRE_64BIT_TIME=
 
+add_time_offset() {
+	case "$3" in
+	hours)
+		unit=$(( 60*60 ))
+		;;
+	days)
+		unit=$(( 24*60*60 ))
+		;;
+	esac
+	offset=$(( $2 * unit ))
+	echo $(( $1 + offset ))
+}
+
 check_approxidate() {
+	old_date=$GIT_TEST_DATE_NOW
+	if test "$3" = "failure"
+	then
+		expection="$3"
+	else
+		expection=${4:-success}
+		offset="$3"
+	fi
+	if test -n "$offset"
+	then
+		GIT_TEST_DATE_NOW=$(add_time_offset $old_date $offset)
+		caption="$1; offset $offset"
+	else
+		caption=$1
+	fi
 	echo "$1 -> $2 +0000" >expect
-	test_expect_${3:-success} "parse approxidate ($1)" "
+	test_expect_$expection "parse approxidate ($caption)" "
 	test-tool date approxidate '$1' >actual &&
 	test_cmp expect actual
 	"
+	GIT_TEST_DATE_NOW=$old_date
 }
 
 check_approxidate now '2009-08-30 19:20:00'
@@ -182,6 +211,8 @@ check_approxidate 'noon today' '2009-08-30 12:00:00'
 check_approxidate 'noon yesterday' '2009-08-29 12:00:00'
 check_approxidate 'January 5th noon pm' '2009-01-05 12:00:00'
 check_approxidate '10am noon' '2009-08-29 12:00:00'
+check_approxidate 'January 5th yesterday' '2009-01-29 19:20:00'
+check_approxidate 'January 5th yesterday' '2008-12-31 19:20:00' '+2 days'
 
 check_approxidate 'last tuesday' '2009-08-25 19:20:00'
 check_approxidate 'July 5th' '2009-07-05 19:20:00'
-- 
2.30.2


  reply	other threads:[~2026-05-14 11:57 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-18 18:01 [PATCH 0/2] approxidate: tweak special date formats Tuomas Ahola
2025-03-18 18:02 ` [PATCH 1/2] approxidate: make "specials" respect fixed day-of-month Tuomas Ahola
2025-04-04  8:19   ` Jeff King
2025-03-18 18:02 ` [PATCH 2/2] approxidate: overwrite tm_mday for `now` and `yesterday` Tuomas Ahola
2025-04-04  8:40   ` Jeff King
2026-05-12 14:54 ` [PATCH v2 0/3] approxidate: tweak special date formats Tuomas Ahola
2026-05-12 14:54   ` [PATCH v2 1/3] t0006: add support for approxidate test date adjustment Tuomas Ahola
2026-05-12 16:34     ` Junio C Hamano
2026-05-12 18:35     ` Jeff King
2026-05-12 14:54   ` [PATCH v2 2/3] approxidate: make "specials" respect fixed day-of-month Tuomas Ahola
2026-05-12 16:52     ` Junio C Hamano
2026-05-12 14:54   ` [PATCH v2 3/3] approxidate: use deferred mday adjustments for "specials" Tuomas Ahola
2026-05-14 11:55   ` [PATCH v3 0/4] approxidate: tweak special date formats Tuomas Ahola
2026-05-14 11:55     ` Tuomas Ahola [this message]
2026-05-14 11:55     ` [PATCH v3 2/4] approxidate: alias "today" to "now" Tuomas Ahola
2026-05-14 15:36       ` Junio C Hamano
2026-05-14 21:07         ` Tuomas Ahola
2026-05-15  1:27           ` Junio C Hamano
2026-05-15  1:38             ` Junio C Hamano
2026-05-15  5:02               ` Tuomas Ahola
2026-05-14 11:55     ` [PATCH v3 3/4] approxidate: make "specials" respect fixed day-of-month Tuomas Ahola
2026-05-14 16:06       ` Junio C Hamano
2026-05-14 11:55     ` [PATCH v3 4/4] approxidate: use deferred mday adjustments for "specials" Tuomas Ahola

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260514115520.6660-2-taahol@utu.fi \
    --to=taahol@utu.fi \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox