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

[Michael J Gruber <git@drmicha.warpmail.net>]

Jakub Narebski venit, vidit, dixit 02.08.2010 23:48:
> "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.

Hmm, sizeof(time_t) == 8 for my x86_64 Fedora, but committing ancient
times fails.

My ctime() happily converts negative numbers into dates before the epoch.

> 
> 64-bit time_t would be enough for everyone (sic!).
> 
> References:
> -----------
> http://en.wikipedia.org/wiki/Unix_epoch

Junio replied:
>I thought the internal representation of our time was "unsigned long", >no?
>How can you represent anything before Unix epoch?

We have a mix of time_t and unsigned long (not signed, not long long!),
and we have our own tm_to_time_t() in date.c which explicitly forbids
years before 1970. It seems we don't use standard ctime() and friends
because the standards is not so standard and want to be independent of
that, but sizeof(long) is still system dependent.

Removing the check in tm_to_time_t() by brute force let's me commit
ancient times, but the parser gets them wrong (either on input or on
output, I haven't checked), 1787 ends up output as 1899.

time_t is signed on most systems. Using unsigned long buys us a few
years as long as we don't go through any system routine nor conversion
to time_t. So maybe we should:

- check to make sure we use time_t and system routines only when getting
the current time
- use signed long long as our git_time_t (I think long is less system
dependent then long but I could be wrong)
- make our own algorithms work for the extended format

Michael