Re: [RFC/PATCH 0/2] Commits with ancient timestamps

Thomas Rast [off-list ref] writes:

Doing this just makes me wonder how important exactly the 1970-1975
range is.  Is there a notable software history from that era that can be
recovered?

That is not really a valid question. People who wrote private stuff in
that era deserve to be users of Git, too.

(Your [1/2] does not seem to parse negative offsets from the unix epoch,
so anything before 1970 is still out.)

Yes, pre-epoch timestamps are also useful for projects like US
Constitution.

  http://thread.gmane.org/gmane.comp.version-control.git/152433/focus=152725

For that, we would need to use and pass around time_t (or intmax_t if we
follow the reason why originally Linus chose to avoid time_t) throughout
the codebase.  If you actually write commit objects that record pre-epoch
timestamps, however, they will become unreadable by the current versions
of Git (as they would not understand such a negative raw timestamp).

In any case, that is a goal for a much longer term.

But even after such a change happens, you still need a way for Git to
replay a raw timestamp stored in commit objects without regressing the
parse_date() interface too much. These two patches show one way to do so
with minimum disruption.

As an added bonus, with the second patch, the way to spell a raw timestamp
happens to become compatible with how GNU date accepts one, i.e.

        $ date -d @1000000000

even though we do not have to encourage the use of this notation by humans,
tools and script writers may find it useful.