On Tue, 4 Sep 2007, Jonas Berlin wrote: > > The timestamp format used in "cvs log" output does not include a > timezone, and must thus be in UTC timezone. The timestamps from git on > the other hand contain timezone information for each commit timestamp, > but git-cvsserver discarded this information and used the timestamps > without adjusting the time accordingly. The patch adds code to apply > the timezone offset to produce a UTC timestamp. I think this is wrong. Git *internally* stores things in UTC anyway, so if there are any local date format things, it's because git-cvsserver.perl has read the dates using some format where git has turned its internal date into a local date. So instead of turning it back into UTC here, I think git-cvsserver should be changed to ask for the date in the native git format in the first place. That can be done various ways: - use the "raw log format" which has dates as seconds-since-UTC (and with an *informational* timezone thing that should then just be ignored). This is likely the best approach, since anything but this will almost invariably result in some potentially broken TZ conversion back-and-forth.. - if it really wants to use the pretty-printing support, git-cvsserver should probably be changed to do something like TZ=UTC git rev-list --pretty --date=local which will pretty-print the date in local time format rather than in the timezone that the commit was done in, and then the TZ=UTC obviously says that the "local" zone is UTC. Anything else *will* be broken, or will be converting back-and-forth. For example, I think your patch may fix "cvs log", but I'm seeing some suspiciously similar code in the "cvs annotate" handling, so I suspect that would need it too. If instead of trying to convert things to UTC on demand, git-cvsserver just asks for the git date stamps in UTC in the first place, none of the places should ever need any timezone conversion. Linus - 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
