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

[Jakub Narebski <jnareb@gmail.com>]

"Joel C. Salomon" <joelcsalomon@gmail.com> 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