"Joel C. Salomon" <joelcsalomon@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html