Re: What's cooking in git.git (Oct 2012, #09; Mon, 29)

[Chris Rorvick <chris@rorvick.com>]

On Thu, Nov 1, 2012 at 1:40 PM, Ramsay Jones <ramsay@ramsay1.demon.co.uk> wrote:
> Jeff King wrote:
>> What's cooking in git.git (Oct 2012, #09; Mon, 29)
>> --------------------------------------------------
>>
>
> [snip]
>
>> * cr/cvsimport-local-zone (2012-10-16) 1 commit
>>  - git-cvsimport: allow author-specific timezones
>>
>>  Allows "cvsimport" to read per-author timezone from the author info
>>  file.
>>
>>  Will merge to 'next'.
>
> Just FYI, t9604-cvsimport-timestamps.sh is still failing for me.
>
> I haven't spent too long on this yet, but I had hoped that setting
> TZ would sidestep any DST issues. (I have downloaded new tzdata, but
> have yet to install - actually I don't really want to!). It is not
> clear from the tzset manpage what happens if you use the DST format
> for TZ, but you don't provide the start/end date for DST, which is
> what this test is doing.
>
> Perhaps the test should use the non-DST format? e.g. "TZ=CST6 git ..."
> Does the test really care about DST? (*if* that is indeed the problem).

It actually looks like your TZ database is fine and the problem is
with the conversion to a struct tm.  In each case, the time is
localized to the previous TZ value while the offset for the current TZ
value.  For example, look at the first commit in the first test.  It
converted the timestamp to 18:00 (CST6) while all the rest came
through as expected.    I suspect the previous version of cvsimport
would exhibit similar behavior with the first imported commit.  What
is your platform?

> Also: Note that the first test calls git-cvsimport twice, first *with*
> TZ set then again without; I suspect a cut/paste editing error.

Oops.  The second invocation should have no effect on the repo so the
unit test is still valid, but that was a mistake for sure.  Thanks.

Chris