Shawn O. Pearce <spearce@spearce.org> wrote:
quoted text > 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
> ~~~~~~~~~~~~
[...]
quoted text > +
> 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.
No, it can't. There are summer/winter times, etc.
quoted text > +
> 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.
Say what? If I use the "raw" format with UTC offset, the offset is just
ignored then?
quoted text > +
> If the source material is formatted in RFC 2822 style dates,
"uses RFC 2822 style dates" would be better
quoted text > 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
"already uses Unix-epoch format, can be coaxed to give dates in that
format, or its format is easily convertible to it" sounds better to me
quoted text > 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>`.
[...]
quoted text > +
> If separate `author` and `committer` commands are used in a `commit`
> the timestamps may not match, as the system clock will be polled
> twice (once for each command).
Better fix that. It can't be that costly to call gettimeofday(2) once and
squirrel the result away for later use.
quoted text > The only way to ensure that both
> author and committer identity information has the same timestamp
> is to omit `author` (thus copying from `committer`) or to use a
> date format other than `now`.
See?
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
majordomo@vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html
