Re: [PATCH 3/3] t0006-date.sh: add `human` date format tests.

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 3, 2019, 21:45 UTC
Message-ID: <xmqq1s5th0u4.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <a5412274-028f-3662-e4f5-dbbcad4d9a40@iee.org>

Philip Oakley <philipoakley@iee.org> writes:

Show 22 quoted lines

> On 02/01/2019 18:15, Junio C Hamano wrote:
>> We perhaps can use "test-tool date timestamp", like so
>>
>> 	check_human_date $(test-tool date timestamp "18000 seconds ago") ...
>>
>> or moving the part that munges 18000 into the above form inside
>> check_human_date helper function, e.g.
>>
>> 	check_human_date () {
>> 		commit_date=$(test-tool date timestamp "$1 seconds ago")
>> 		commit_date="$commit_date +0200"
>>                  expect=$2
>> 		...
>> 	}
>>
>> which would let us write
>>
>> 	check_human_date 432000 "$THIS_YEAR_REGEX" # 5 days ago
>
>
> Just a quick bikeshed: if used, would this have a year end 5 day
> roll-over error potential, or will it always use the single date?

Hmph, interesting point. Indeed, date.c::show_date_normal() decides to hide the year portion if the timestamp and the current time share the same year, so on Thu Jan 3rd, an attempt to show a commit made on Mon Dec 31st of the same week would end up showing the year, so yes, I agree with you that the above would break.

+TODAY_REGEX='5 hours ago' +THIS_YEAR_REGEX='[A-Z][a-z][a-z] [A-Z][a-z][a-z] [0-9]* [012][0-9]:[0-6][0-9]' +MORE_THAN_A_YEAR_REGEX='[A-Z][a-z][a-z] [A-Z][a-z][a-z] [0-9]* [0-9][0-9][0-9][0-9]'

>
> (I appreciate it is just suggestion code, not tested)