From: Linus Torvalds Date: Thu, 26 May 2005 04:20:44 GMT Subject: Re: new cvsps version fixes issues for cvs2git Message-ID: In-Reply-To: <42954A6D.6020503@cobite.com> On Thu, 26 May 2005, David Mansfield wrote: > > 4) patchset date/time problems. the date/time handling was bogus. some > of it was patched for some time in my tree, but not released. also we > now report all dates in LOCALTIME. use the TZ variable to get a > different time. Note: 'cvs log' format is always UTC. > > Linus, based on #4, you may want to set 'export TZ=UTC' before running, > and handle date/time conversion in cvs2git counting on that. otherwise, > I think problems may occur with daylight savings (apr/oct). cvs2git only wants UTC times, and doesn't do any conversion, since that's the native git format (git considers all times to be UTC, but also records a "what timezone was the thing done in" so that if you want to, you can print it out not in localtime, but in "localtime as it was for the committer"). Nothing else really makes sense - it's totally senseless to print it out as "in localtime of user". Since the CVS information doesn't contain any timezone, it would be bogus to use one, and the only sane git conversion is to always use UTC. Using the timezone of the converter is also bogus, since that just makes different converters get different results. So I'd much rather see you add a flag that just always does the native CVS time (ie UTC)? Quite frankly, it's wrong to do anything else, exactly because it makes no sense to print out dates in a timezone that has no relevance (what relevance does Pacitic time have for somebody who committed something at 8AM Eastern? _None_). The fact is, if we depend on people doign "TZ=UTC", people will forget, and then people will have different conversions. (My personal preference would be to _default_ to UTC, and instead have a special flag that says "use localtime to print stuff out", since localtime really is the least relevant one most of the time) Linus