Re: git-fast-import

[Linus Torvalds <torvalds@linux-foundation.org>]

On Tue, 6 Feb 2007, Horst H. von Brand wrote:
>
> Shawn O. Pearce <spearce@spearce.org> wrote:
> 
> [...]
> 
> > What about this language?
> > 
> > 	The time of the change is specified by `<time>` as the number of
> > 	seconds since the UNIX epoc (midnight, Jan 1, 1970, UTC) and is
> > 	written in base-10 notation using US-ASCII digits.  The committer's
> > 	timezone is specified by `<tz>` as a positive or negative offset
> > 	from UTC.  For example EST (which is typically 5 hours behind GMT)
> > 	would be expressed in `<tz>` by ``-0500'' while GMT is ``+0000''.
> 
> That is /not/ a timezone! Maybe an offset from UTC.

Btw, one thing that might be a good idea to document very clearly:

 - in the native git format, the offset from UTC has *nothing* to do with 
   the actual time itself. The time in native git is always in UTC, and 
   the offset from UTC does not change "time" - it's purely there to tell 
   in which timezone the event happened.

   So 12345678 +0000 and 12345678 -0700 are *exactly*the*same*date*, 
   except event one happened in UTC, and the other happened in UTC-7.

 - in rfc2822 format, the offset from UTC actually *changes* the date. The 
   date "Oct 12, 2006 20:00:00" will be two _different_ times when you say 
   it is in PST or in UTC.

And yes, for all I know we might get this wrong inside git too. It's easy 
to get confused, because they really do mean different things.

For an example of this, do

	make test-date

in git (which parses the argument using the "exact date" and "approxidate" 
versions respectively, and the exact date parsing will give the internal 
git representation on the first line in the middle column), and then:

	./test-date "1234567890 -0800"
	./test-date "1234567890 +0000"

and then try

	./test-date "Fri Feb 13 15:31:30 2009 PST"
	./test-date "Fri Feb 13 15:31:30 2009 UTC"

and notice how the first two (numeric) dates that differ in UTC offset 
will still return the exact same seconds since the epoch:

	1234567890 -0800
	1234567890 +0000

but the second example (with a rfc2822-like date), will show how the 
seconds-since-epoch changes, and gives:

	1234567890 -0800
	1234539090 +0000

respectively for those two dates.

Logical? It actually is, but you have to understand how git represents 
date to see the logic. To git, the "timezone" is really totally 
irrelevant. It doesn't really affect the "date" at all. At most, it 
affects how you _print_ the date, and you can tell what timezone the 
computer was set to when the commit was made.

And yes, I would not be at all surprised if we had some bug here where we 
got it wrong occasionally.

		Linus