On Thu, Nov 1, 2012 at 1:40 PM, Ramsay Jones <ramsay@xxxxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html