Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote: > Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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. No, it can't. There are summer/winter times, etc. > + > 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? > + > If the source material is formatted in RFC 2822 style dates, "uses RFC 2822 style dates" would be better > 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 > 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>`. [...] > + > 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. > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html