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

From: Jakub Narebski <jnareb@gmail.com>
Date: Aug 2, 2010, 21:48 UTC
Message-ID: <m3hbjcptyr.fsf@localhost.localdomain>
In-Reply-To: <i372v0$3np$1@dough.gmane.org>

"Joel C. Salomon" <joelcsalomon@gmail.com> writes:

Show 16 quoted lines

> 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