mirrors/git
1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-06 01:03:02 +01:00
Code Activity
git/t/t0006-date.sh

130 lines
4.5 KiB
Bash
Raw Normal View History

tests: add date printing and parsing tests 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-31 04:30:16 +02:00
#!/bin/sh
test_description='test date parsing and printing'
. ./test-lib.sh
# arbitrary reference time: 2009-08-30 19:20:00
TEST_DATE_NOW=1251660000; export TEST_DATE_NOW
t0006: rename test-date's "show" to "relative" The "show" tests are really only checking relative formats; we should make that more clear. This also frees up the "show" name to later check other formats. We could later fold "relative" into a more generic "show" command, but it's not worth it. Relative times are a special case already because we have to munge the concept of "now" in our tests. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20 23:10:29 +02:00
check_relative() {
tests: add date printing and parsing tests 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-31 04:30:16 +02:00
t=$(($TEST_DATE_NOW - $1))
echo "$t -> $2" >expect
test_expect_${3:-success} "relative date ($2)" "
t0006: rename test-date's "show" to "relative" The "show" tests are really only checking relative formats; we should make that more clear. This also frees up the "show" name to later check other formats. We could later fold "relative" into a more generic "show" command, but it's not worth it. Relative times are a special case already because we have to munge the concept of "now" in our tests. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20 23:10:29 +02:00
test-date relative $t >actual &&
Fix tests under GETTEXT_POISON on relative dates Use the i18n-specific test_i18ncmp in t/t0006-date.sh for relative dates tests. This issue was was introduced in v1.7.10-230-g7d29a: 7d29a i18n: mark relative dates for translation and been broken under GETTEXT_POISON=YesPlease since. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27 07:36:49 +02:00
test_i18ncmp expect actual
tests: add date printing and parsing tests 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-31 04:30:16 +02:00
"
}
t0006: rename test-date's "show" to "relative" The "show" tests are really only checking relative formats; we should make that more clear. This also frees up the "show" name to later check other formats. We could later fold "relative" into a more generic "show" command, but it's not worth it. Relative times are a special case already because we have to munge the concept of "now" in our tests. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20 23:10:29 +02:00
check_relative 5 '5 seconds ago'
check_relative 300 '5 minutes ago'
check_relative 18000 '5 hours ago'
check_relative 432000 '5 days ago'
check_relative 1728000 '3 weeks ago'
check_relative 13000000 '5 months ago'
check_relative 37500000 '1 year, 2 months ago'
check_relative 55188000 '1 year, 9 months ago'
check_relative 630000000 '20 years ago'
check_relative 31449600 '12 months ago'
check_relative 62985600 '2 years ago'
tests: add date printing and parsing tests 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-31 04:30:16 +02:00
t0006: test various date formats We ended up testing some of these date formats throughout the rest of the suite (e.g., via for-each-ref's "$(authordate:...)" format), but we never did so systematically. t0006 is the right place for unit-testing of our date-handling code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20 23:11:59 +02:00
check_show () {
format=$1
time=$2
expect=$3
t0006: check --date=format zone offsets We already test that "%z" and "%Z" show the right thing, but we don't actually check that the time we display is the correct one. Let's add two new tests: 1. Test that "format:" shows the time in the author's timezone, just like the other time formats. 2. Test that "format-local:" shows time in the local timezone. We don't want to use our normal UTC for this, because its offset is zero (so the result would be "correct" even if the code forgot to apply the offset or applied it in the wrong direction). We'll use the EST5 zone, which is already used elsewhere in the script (and so is assumed to be available everywhere). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-15 15:51:22 +02:00
prereqs=$4
zone=$5
test_expect_success $prereqs "show date ($format:$time)" '
t0006: test various date formats We ended up testing some of these date formats throughout the rest of the suite (e.g., via for-each-ref's "$(authordate:...)" format), but we never did so systematically. t0006 is the right place for unit-testing of our date-handling code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20 23:11:59 +02:00
echo "$time -> $expect" >expect &&
t0006: check --date=format zone offsets We already test that "%z" and "%Z" show the right thing, but we don't actually check that the time we display is the correct one. Let's add two new tests: 1. Test that "format:" shows the time in the author's timezone, just like the other time formats. 2. Test that "format-local:" shows time in the local timezone. We don't want to use our normal UTC for this, because its offset is zero (so the result would be "correct" even if the code forgot to apply the offset or applied it in the wrong direction). We'll use the EST5 zone, which is already used elsewhere in the script (and so is assumed to be available everywhere). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-15 15:51:22 +02:00
TZ=${zone:-$TZ} test-date show:"$format" "$time" >actual &&
t0006: test various date formats We ended up testing some of these date formats throughout the rest of the suite (e.g., via for-each-ref's "$(authordate:...)" format), but we never did so systematically. t0006 is the right place for unit-testing of our date-handling code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20 23:11:59 +02:00
test_cmp expect actual
'
}
# arbitrary but sensible time for examples
TIME='1466000000 +0200'
check_show iso8601 "$TIME" '2016-06-15 16:13:20 +0200'
check_show iso8601-strict "$TIME" '2016-06-15T16:13:20+02:00'
check_show rfc2822 "$TIME" 'Wed, 15 Jun 2016 16:13:20 +0200'
check_show short "$TIME" '2016-06-15'
check_show default "$TIME" 'Wed Jun 15 16:13:20 2016 +0200'
check_show raw "$TIME" '1466000000 +0200'
date: add "unix" format We already have "--date=raw", which is a Unix epoch timestamp plus a contextual timezone (either the author's or the local). But one may not care about the timezone and just want the epoch timestamp by itself. It's not hard to parse the two apart, but if you are using a pretty-print format, you may want git to show the "finished" form that the user will see. We can accomodate this by adding a new date format, "unix", which is basically "raw" without the timezone. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-22 21:51:49 +02:00
check_show unix "$TIME" '1466000000'
t0006: test various date formats We ended up testing some of these date formats throughout the rest of the suite (e.g., via for-each-ref's "$(authordate:...)" format), but we never did so systematically. t0006 is the right place for unit-testing of our date-handling code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20 23:11:59 +02:00
check_show iso-local "$TIME" '2016-06-15 14:13:20 +0000'
date: document and test "raw-local" mode The "raw" format shows a Unix epoch timestamp, but with a timezone tacked on. The timestamp is not _in_ that zone, but it is extra information about the time (by default, the zone the author was in). The documentation claims that "raw-local" does not work. It does, but the end result is rather subtle. Let's describe it in better detail, and test to make sure it works (namely, the epoch time doesn't change, but the zone does). While we are rewording the documentation in this area, let's not use the phrase "does not work" for the remaining option, "--date=relative". It's vague; do we accept it or not? We do accept it, but it has no effect (which is a reasonable outcome). We should also refer to the option not as "--relative" (which is the historical synonym, and does not take "-local" at all), but as "--date=relative". Helped-by: Jakub Narębski <jnareb@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-27 15:44:41 +02:00
check_show raw-local "$TIME" '1466000000 +0000'
date: add "unix" format We already have "--date=raw", which is a Unix epoch timestamp plus a contextual timezone (either the author's or the local). But one may not care about the timezone and just want the epoch timestamp by itself. It's not hard to parse the two apart, but if you are using a pretty-print format, you may want git to show the "finished" form that the user will see. We can accomodate this by adding a new date format, "unix", which is basically "raw" without the timezone. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-22 21:51:49 +02:00
check_show unix-local "$TIME" '1466000000'
t0006: test various date formats We ended up testing some of these date formats throughout the rest of the suite (e.g., via for-each-ref's "$(authordate:...)" format), but we never did so systematically. t0006 is the right place for unit-testing of our date-handling code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20 23:11:59 +02:00
strbuf: let strbuf_addftime handle %z and %Z itself There is no portable way to pass timezone information to strftime. Add parameters for timezone offset and name to strbuf_addftime and let it handle the timezone-related format specifiers %z and %Z internally. Callers can opt out for %Z by passing NULL as timezone name. %z is always handled internally -- this helps on Windows, where strftime would expand it to a timezone name (same as %Z), in violation of POSIX. Modifiers are not handled, e.g. %Ez is still passed to strftime. Use an empty string as timezone name in show_date (the only current caller) for now because we only have the timezone offset in non-local mode. POSIX allows %Z to resolve to an empty string in case of missing information. Helped-by: Ulrich Mueller <ulm@gentoo.org> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-15 14:29:53 +02:00
check_show 'format:%z' "$TIME" '+0200'
check_show 'format-local:%z' "$TIME" '+0000'
check_show 'format:%Z' "$TIME" ''
date: use localtime() for "-local" time formats When we convert seconds-since-epochs timestamps into a broken-down "struct tm", we do so by adjusting the timestamp according to the known offset and then using gmtime() to break down the result. This means that the resulting struct "knows" that it's in GMT, even though the time it represents is adjusted for a different zone. The fields where it stores this data are not portably accessible, so we have no way to override them to tell them the real zone info. For the most part, this works. Our date-formatting routines don't pay attention to these inaccessible fields, and use the same tz info we provided for adjustment. The one exception is when we call strftime(), whose %Z format reveals this hidden timezone data. We solved that by always showing the empty string for %Z. This is allowed by POSIX, but not very helpful to the user. We can't make this work in the general case, as there's no portable function for setting an arbitrary timezone (and anyway, we don't have the zone name for the author zones, only their offsets). But for the special case of the "-local" formats, we can just skip the adjustment and use localtime() instead of gmtime(). This makes --date=format-local:%Z work correctly, showing the local timezone instead of an empty string. The new test checks the result for "UTC", our default test-lib value for $TZ. Using something like EST5 might be more interesting, but the actual zone string is system-dependent (for instance, on my system it expands to just EST). Hopefully "UTC" is vanilla enough that every system treats it the same. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-15 15:52:17 +02:00
check_show 'format-local:%Z' "$TIME" 'UTC'
strbuf: let strbuf_addftime handle %z and %Z itself There is no portable way to pass timezone information to strftime. Add parameters for timezone offset and name to strbuf_addftime and let it handle the timezone-related format specifiers %z and %Z internally. Callers can opt out for %Z by passing NULL as timezone name. %z is always handled internally -- this helps on Windows, where strftime would expand it to a timezone name (same as %Z), in violation of POSIX. Modifiers are not handled, e.g. %Ez is still passed to strftime. Use an empty string as timezone name in show_date (the only current caller) for now because we only have the timezone offset in non-local mode. POSIX allows %Z to resolve to an empty string in case of missing information. Helped-by: Ulrich Mueller <ulm@gentoo.org> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-15 14:29:53 +02:00
check_show 'format:%%z' "$TIME" '%z'
check_show 'format-local:%%z' "$TIME" '%z'
t0006: check --date=format zone offsets We already test that "%z" and "%Z" show the right thing, but we don't actually check that the time we display is the correct one. Let's add two new tests: 1. Test that "format:" shows the time in the author's timezone, just like the other time formats. 2. Test that "format-local:" shows time in the local timezone. We don't want to use our normal UTC for this, because its offset is zero (so the result would be "correct" even if the code forgot to apply the offset or applied it in the wrong direction). We'll use the EST5 zone, which is already used elsewhere in the script (and so is assumed to be available everywhere). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-15 15:51:22 +02:00
check_show 'format:%Y-%m-%d %H:%M:%S' "$TIME" '2016-06-15 16:13:20'
check_show 'format-local:%Y-%m-%d %H:%M:%S' "$TIME" '2016-06-15 09:13:20' '' EST5
local_tzoffset: detect errors from tm_to_time_t When we want to know the local timezone offset at a given timestamp, we compute it by asking for localtime() at the given time, and comparing the offset to GMT at that time. However, there's some juggling between time_t and "struct tm" which happens, which involves calling our own tm_to_time_t(). If that function returns an error (e.g., because it only handles dates up to the year 2099), it returns "-1", which we treat as a time_t, and is clearly bogus, leading to bizarre timestamps (that seem to always adjust the time back to (time_t)(uint32_t)-1, in the year 2106). It's not a good idea for local_tzoffset() to simply die here; it would make it hard to run "git log" on a repository with funny timestamps. Instead, let's just treat such cases as "zero offset". Reported-by: Norbert Kiesel <nkiesel@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20 23:14:14 +02:00
# arbitrary time absurdly far in the future
FUTURE="5758122296 -0400"
t0006 & t5000: skip "far in the future" test when time_t is too limited Git's source code refers to timestamps as unsigned long, which is ill-defined, as there is no guarantee about the number of bits that data type has. In preparation of switching to another data type that is large enough to hold "far in the future" dates, we need to prepare the t0006-date.sh script for the case where we *still* cannot format those dates if the system library uses 32-bit time_t. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-20 22:58:21 +02:00
check_show iso "$FUTURE" "2152-06-19 18:24:56 -0400" TIME_IS_64BIT,TIME_T_IS_64BIT
check_show iso-local "$FUTURE" "2152-06-19 22:24:56 +0000" TIME_IS_64BIT,TIME_T_IS_64BIT
local_tzoffset: detect errors from tm_to_time_t When we want to know the local timezone offset at a given timestamp, we compute it by asking for localtime() at the given time, and comparing the offset to GMT at that time. However, there's some juggling between time_t and "struct tm" which happens, which involves calling our own tm_to_time_t(). If that function returns an error (e.g., because it only handles dates up to the year 2099), it returns "-1", which we treat as a time_t, and is clearly bogus, leading to bizarre timestamps (that seem to always adjust the time back to (time_t)(uint32_t)-1, in the year 2106). It's not a good idea for local_tzoffset() to simply die here; it would make it hard to run "git log" on a repository with funny timestamps. Instead, let's just treat such cases as "zero offset". Reported-by: Norbert Kiesel <nkiesel@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20 23:14:14 +02:00
tests: add date printing and parsing tests 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-31 04:30:16 +02:00
check_parse() {
echo "$1 -> $2" >expect
t0006: test timezone parsing Previously, test-date simply ignored the parsed timezone and told show_date() to use UTC. Instead, let's print out what we actually parsed. While we're at it, let's make it easy for tests to work in a specific timezone. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-04 12:48:35 +02:00
test_expect_${4:-success} "parse date ($1${3:+ TZ=$3})" "
TZ=${3:-$TZ} test-date parse '$1' >actual &&
tests: add date printing and parsing tests 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-31 04:30:16 +02:00
test_cmp expect actual
"
}
check_parse 2008 bad
check_parse 2008-02 bad
check_parse 2008-02-14 bad
check_parse '2008-02-14 20:30:45' '2008-02-14 20:30:45 +0000'
t0006: test timezone parsing Previously, test-date simply ignored the parsed timezone and told show_date() to use UTC. Instead, let's print out what we actually parsed. While we're at it, let's make it easy for tests to work in a specific timezone. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-04 12:48:35 +02:00
check_parse '2008-02-14 20:30:45 -0500' '2008-02-14 20:30:45 -0500'
date.c: Support iso8601 timezone formats Timezone designators in the following formats are all valid according to ISO8601:2004, section 4.3.2: [+-]hh, [+-]hhmm, [+-]hh:mm but we have ignored the ones with colon so far. Signed-off-by: Haitao Li <lihaitao@gmail.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-09 12:10:33 +02:00
check_parse '2008-02-14 20:30:45 -0015' '2008-02-14 20:30:45 -0015'
check_parse '2008-02-14 20:30:45 -5' '2008-02-14 20:30:45 +0000'
check_parse '2008-02-14 20:30:45 -5:' '2008-02-14 20:30:45 +0000'
check_parse '2008-02-14 20:30:45 -05' '2008-02-14 20:30:45 -0500'
check_parse '2008-02-14 20:30:45 -:30' '2008-02-14 20:30:45 +0000'
check_parse '2008-02-14 20:30:45 -05:00' '2008-02-14 20:30:45 -0500'
t/t0006: specify timezone as EST5 not EST to comply with POSIX POSIX requires that both the timezone "standard" and "offset" be specified in the TZ environment variable. This causes a problem on IRIX which does not understand the timezone 'EST'. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-07 01:34:20 +02:00
check_parse '2008-02-14 20:30:45' '2008-02-14 20:30:45 -0500' EST5
tests: add date printing and parsing tests 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-31 04:30:16 +02:00
check_approxidate() {
echo "$1 -> $2 +0000" >expect
test_expect_${3:-success} "parse approxidate ($1)" "
test-date approxidate '$1' >actual &&
test_cmp expect actual
"
}
check_approxidate now '2009-08-30 19:20:00'
check_approxidate '5 seconds ago' '2009-08-30 19:19:55'
check_approxidate 5.seconds.ago '2009-08-30 19:19:55'
check_approxidate 10.minutes.ago '2009-08-30 19:10:00'
check_approxidate yesterday '2009-08-29 19:20:00'
check_approxidate 3.days.ago '2009-08-27 19:20:00'
check_approxidate 3.weeks.ago '2009-08-09 19:20:00'
fix approxidate parsing of relative months and years 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-31 04:31:42 +02:00
check_approxidate 3.months.ago '2009-05-30 19:20:00'
check_approxidate 2.years.3.months.ago '2007-05-30 19:20:00'
tests: add date printing and parsing tests 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-31 04:30:16 +02:00
check_approxidate '6am yesterday' '2009-08-29 06:00:00'
check_approxidate '6pm yesterday' '2009-08-29 18:00:00'
check_approxidate '3:00' '2009-08-30 03:00:00'
check_approxidate '15:00' '2009-08-30 15:00:00'
check_approxidate 'noon today' '2009-08-30 12:00:00'
check_approxidate 'noon yesterday' '2009-08-29 12:00:00'
check_approxidate 'last tuesday' '2009-08-25 19:20:00'
check_approxidate 'July 5th' '2009-07-05 19:20:00'
check_approxidate '06/05/2009' '2009-06-05 19:20:00'
check_approxidate '06.05.2009' '2009-05-06 19:20:00'
check_approxidate 'Jun 6, 5AM' '2009-06-06 05:00:00'
check_approxidate '5AM Jun 6' '2009-06-06 05:00:00'
check_approxidate '6AM, June 7, 2009' '2009-06-07 06:00:00'
approxidate: allow ISO-like dates far in the future When we are parsing approxidate strings and we find three numbers separate by one of ":/-.", we guess that it may be a date. We feed the numbers to match_multi_number, which checks whether it makes sense as a date in various orderings (e.g., dd/mm/yy or mm/dd/yy, etc). One of the checks we do is to see whether it is a date more than 10 days in the future. This was added in 38035cf (date parsing: be friendlier to our European friends., 2006-04-05), and lets us guess that if it is currently April 2014, then "10/03/2014" is probably March 10th, not October 3rd. This has a downside, though; if you want to be overly generous with your "--until" date specification, we may wrongly parse "2014-12-01" as "2014-01-12" (because the latter is an in-the-past date). If the year is a future year (i.e., both are future dates), it gets even weirder. Due to the vagaries of approxidate, months _after_ the current date (no matter the year) get flipped, but ones before do not. This patch drops the "in the future" check for dates of this form, letting us treat them always as yyyy-mm-dd, even if they are in the future. This does not affect the normal dd/mm/yyyy versus mm/dd/yyyy lookup, because this code path only kicks in when the first number is greater than 70 (i.e., it must be a year, and cannot be either a date or a month). The one possible casualty is that "yyyy-dd-mm" is less likely to be chosen over "yyyy-mm-dd". That's probably OK, though because: 1. The difference happens only when the date is in the future. Already we prefer yyyy-mm-dd for dates in the past. 2. It's unclear whether anybody even uses yyyy-dd-mm regularly. It does not appear in lists of common date formats in Wikipedia[1,2]. 3. Even if (2) is wrong, it is better to prefer ISO-like dates, as that is consistent with what we use elsewhere in git. [1] http://en.wikipedia.org/wiki/Date_and_time_representation_by_country [2] http://en.wikipedia.org/wiki/Calendar_date Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-13 22:43:31 +01:00
check_approxidate '2008-12-01' '2008-12-01 19:20:00'
check_approxidate '2009-12-01' '2009-12-01 19:20:00'
tests: add date printing and parsing tests 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-31 04:30:16 +02:00
test_done
Copy permalink