git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Jonas Berlin <xkr47@outerspace.dyndns.org>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Fix "cvs log" to use UTC timezone instead of local
Date: Tue, 4 Sep 2007 06:22:25 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.0.999.0709040612260.3088@evo.linux-foundation.org> (raw)
In-Reply-To: <11889090932256-git-send-email-xkr47@outerspace.dyndns.org>



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

  reply	other threads:[~2007-09-04 13:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-04 12:31 [PATCH] Fix "cvs log" to use UTC timezone instead of local Jonas Berlin
2007-09-04 13:22 ` Linus Torvalds [this message]
2007-09-05 21:32   ` Jonas Berlin
2007-09-05 21:45     ` Jonas Berlin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.0.999.0709040612260.3088@evo.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=git@vger.kernel.org \
    --cc=xkr47@outerspace.dyndns.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).