in the `--date-format=<fmt>` command line option.
- This is the Git native format and is `<time> SP <
+ This is the Git native format and is `<time> SP <>`.
It is also gfi's default format, if `--date-format` was
seconds since the UNIX epoch (midnight, Jan 1, 1970, UTC) and is
written as an ASCII decimal integer.
-The 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''.
+The local offset is specified by `<offutc>` as a positive or negative
+offset from UTC. For example EST (which is 5 hours behind UTC)
+would be expressed in `<tz>` by ``-0500'' while UTC is ``+0000''.
+The local offset does not affect `<time>`; it is used only as an
+advisement to help formatting routines display the timestamp.
-If the timezone is not available in the source material, use
-``+0000'', or the most common local timezone. For example many
+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
user's timezone can be easily assumed.
+case the can be easily assumed.
Unlike the `rfc2822` format, this format is very strict. Any
variation in formatting will cause gfi to reject the value.
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.
If the source material is formatted in RFC 2822 style dates,
the frontend should let gfi handle the parsing and conversion
(rather than attempting to do it itself) as the Git parser has