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
next prev parent 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