Re: Back-dating commits--way back--for constitution.git

"Joel C. Salomon" [off-list ref] writes:

I'd figured to play with Git in an unusual way: to create a repository
for the U.S. Constitution where amendments are presented as patches.
E.g., instead of the First Amendment being placed at the end (as is
usual) I'm putting it in Article 1, Section 9 (Limitations of Congress).
 Proposed amendments get branches, which get merged in later.

But I'm trying to get the dates right, and I'm missing something.  For
example, I made the initial commit with the line

	$ git commit --author="The Philadelphia Convention <>" \
	 --date="Mon, 17 Sep 1787 12:00:00 EST"

but that's not actually setting the commit date to 1787.

Am I doing something wrong, or is Git (quite reasonably) unable to
accept commit dates that far in the past?

Git encodes author and commit (and tagger) time using Unix epoch
(POSIX epoch) plus timezone.  As Shawn and Ævar wrote on 32-bit
systems time_t can cover a range of about 136 years in total around
January 1, 1970, which means that the maximum representable time on
32-bit system is 2038-01-19 (the year 2038 problem), but what is more
important to you is that minimum representable time is 1901-12-13.
1787 is too old for 32-bit time_t.

The headers inside commit (and tag) objects are stored in text form,
so they are not limited to 32-bit value.  You would have to use system
that has 64-bit time_t, or patch git.

64-bit time_t would be enough for everyone (sic!).

References:
-----------
http://en.wikipedia.org/wiki/Unix_epoch
-- 
Jakub Narebski
Poland
ShadeHawk on #git