Re: git-fast-import

> Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > 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.
> 
> Here is the current language relating to date parsing in gfi:
> 
> Date Formats
> ~~~~~~~~~~~~

> +
> If the local offset is not available in the source material, use
> ``+0000'', or the most common local offset.  For example many
> organizations have a CVS repository which has only ever been accessed
> by users who are located in the same location and timezone.  In this
> case the offset from UTC can be easily assumed.

> +
> Unlike the `rfc2822` format, this format is very strict.  Any
> variation in formatting will cause gfi to reject the value.
> 
> `rfc2822`::
> 	This is the standard email format as described by RFC 2822.
> +
> An example value is ``Tue Feb 6 11:22:18 2007 -0500''.  The Git
> parser is accurate, but a little on the lenient side.  Its the
> same parser used by gitlink:git-am[1] when applying patches
> received from email.
> +
> Some malformed strings may be accepted as valid dates.  In some of
> these cases Git will still be able to obtain the correct date from
> the malformed string.  There are also some types of malformed
> strings which Git will parse wrong, and yet consider valid.
> Seriously malformed strings will be rejected.
> +
> Unlike the `raw` format above, the timezone/UTC offset information
> contained in an RFC 2822 date string is used to adjust the date
> value to UTC prior to storage.  Therefore it is important that
> this information be as accurate as possible.

> the frontend should let gfi handle the parsing and conversion
> (rather than attempting to do it itself) as the Git parser has
> been well tested in the wild.
> +
> Frontends should prefer the `raw` format if the source material
> is already in UNIX-epoch format, or is easily convertible to

> that format, as there is no ambiguity in parsing.
> 
> `now`::
> 	Always use the current time and timezone.  The literal
> 	`now` must always be supplied for `<when>`.