summaryrefslogtreecommitdiff
path: root/t/t0006-date.sh
AgeCommit message (Collapse)AuthorFilesLines
2016-07-15t0006: skip "far in the future" test when unsigned long is not long enoughLibravatar Jeff King1-3/+3
Git's source code refers to timestamps as unsigned longs. On 32-bit platforms, as well as on Windows, unsigned long is not large enough to capture dates that are "absurdly far in the future". While we can fix this issue properly by replacing unsigned long with a larger type, we want to be a bit more conservative and just skip those tests on the maint track. Signed-off-by: Jeff King <peff@peff.net> Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20local_tzoffset: detect errors from tm_to_time_tLibravatar Jeff King1-0/+5
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-20t0006: test various date formatsLibravatar Jeff King1-0/+21
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-20t0006: rename test-date's "show" to "relative"Libravatar Jeff King1-13/+13
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>
2014-11-13approxidate: allow ISO-like dates far in the futureLibravatar Jeff King1-0/+3
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>
2012-08-27Fix tests under GETTEXT_POISON on relative datesLibravatar Jiang Xin1-1/+1
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>
2011-09-12date.c: Support iso8601 timezone formatsLibravatar Haitao Li1-0/+6
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-04-20date: avoid "X years, 12 months" in relative datesLibravatar Michael J Gruber1-0/+1
When relative dates are more than about a year ago, we start writing them as "Y years, M months". At the point where we calculate Y and M, we have the time delta specified as a number of days. We calculate these integers as: Y = days / 365 M = (days % 365 + 15) / 30 This rounds days in the latter half of a month up to the nearest month, so that day 16 is "1 month" (or day 381 is "1 year, 1 month"). We don't round the year at all, though, meaning we can end up with "1 year, 12 months", which is silly; it should just be "2 years". Implement this differently with months of size onemonth = 365/12 so that totalmonths = (long)( (days + onemonth/2)/onemonth ) years = totalmonths / 12 months = totalmonths % 12 In order to do this without floats, we write the first formula as totalmonths = (days*12*2 + 365) / (365*2) Tests and inspiration by Jeff King. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-07t/t0006: specify timezone as EST5 not EST to comply with POSIXLibravatar Brandon Casey1-1/+1
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-05parse_date: fix signedness in timezone calculationLibravatar Jeff King1-0/+1
When no timezone is specified, we deduce the offset by subtracting the result of mktime from our calculated timestamp. However, our timestamp is stored as an unsigned integer, meaning we perform the subtraction as unsigned. For a negative offset, this means we wrap to a very high number, and our numeric timezone is in the millions of hours. You can see this bug by doing: $ TZ=EST \ GIT_AUTHOR_DATE='2010-06-01 10:00' \ git commit -a -m foo $ git cat-file -p HEAD | grep author author Jeff King <peff@peff.net> 1275404416 +119304128 Instead, we should perform this subtraction as a time_t, the same type that mktime returns. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-05t0006: test timezone parsingLibravatar Jeff King1-2/+3
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>
2009-10-03Fix '--relative-date'Libravatar Johan Sageryd1-0/+1
This fixes '--relative-date' so that it does not give '0 year, 12 months', for the interval 360 <= diff < 365. Signed-off-by: Johan Sageryd <j416@1616.se> Signed-off-by: Jeff King <peff@peff.net>
2009-08-30fix approxidate parsing of relative months and yearsLibravatar Jeff King1-2/+2
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-30tests: add date printing and parsing testsLibravatar Jeff King1-0/+75
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>