On Tue, 3 Aug 2010, Michael J Gruber wrote:
> Jakub Narebski venit, vidit, dixit 02.08.2010 23:48:
>> "Joel C. Salomon" <joelcsalomon@xxxxxxxxx> writes:
>>> [...] 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.
That's because git *porcelain* either does not use time_t consistently,
or has some sanity checks that are good heuristic for ordinary use (like
e.g. commit time not too far in past where git didn't even exists),
or both.
It is not a problem on lowest level, i.e. repository format and plumbing.
I was able to create a commit that had author time before Unix epoch
using plumbing:
1. create an ordinary commit as a template (so I don't have to go down
to the level of gitcore-tutorial:
$ git commit -a
[master 8ddcf60] foo
1 files changed, 1 insertions(+), 0 deletions(-)
2. save commit object in a file, to be edited
$ git cat-file -p HEAD > tmp.txt
3. edit tmp.txt, changing sign of author time
$ [edit tmp.txt]
$ cat tmp.txt
tree 953e0e451fdcb5c21a25ee7ef9faade5791b95ee
parent 6a28c9c996d785b716559f57149a9b5c11fd83ff
author Jakub Narebski <jnareb@xxxxxxxxx> -12808209400 +0200
committer Jakub Narebski <jnareb@xxxxxxxxx> 1280820940 +0200
git-hash-object
4. replace just created commit by handcrafted one
$ git reset --hard HEAD^
$ git hash-object -t commit -w tmp.txt
fa5e5a2b6f27f10ce920ca82ffef07ed3eb3f26f
$ git update-ref -m 'commit: foo' refs/heads/master \
fa5e5a2b6f27f10ce920ca82ffef07ed3eb3f26f
5. check that porcelain parses date correctly
$ git show
commit a5f4eaace56c6887846ea77725e1ac6827bb13b0
Author: Jakub Narebski <jnareb@xxxxxxxxx>
Date: Fri May 31 18:24:20 1929 +0200
git-hash-object
Though when I tried to create commit with authordate further in the past,
porcelain shown 1970 (Unix epoch) as a date, but my system has 32-bit
time_t.
> My ctime() happily converts negative numbers into dates before the epoch.
Try ./test-date in git sources...
> 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.
Hmmm...
--
Jakub Narebski
Poland
--
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