Re: [EGIT PATCH] Committer, author and tagger time should not be parsed as 32 bit signed int

From: Robin Rosenberg <robin.rosenberg.lists@dewire.com>
Date: Dec 18, 2008, 00:09 UTC
Message-ID: <200812180109.51987.robin.rosenberg.lists@dewire.com>
In-Reply-To: <20081217224844.GK32487@spearce.org>

onsdag 17 december 2008 23:48:44 skrev Shawn O. Pearce:

Show 8 quoted lines

> Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> > If not dates past 2038 will be parsed the wrong way when
> > parsed into a RevCommit or RevTag object.
> 
> Uhm, sure.
> 
> But there's also the commitTime field in RevCommit, its used to
> sort commits during walking.  In 2038 that will also overflow.

Ok, but that's not used for display purposes, which what I saw. How huge is the cost of a long here. Most processor handle longs well today, though many megs of them will hurt the cache.

Show 5 quoted lines

> Also, if you search the code for '2038' you'll find a remark
> about the year 2038 in DirCacheEntry.smudgeRacilyClean.  Last
> I looked at the git sources I think this field in the index is
> treated as a signed time_t so we can't set the high bits and
> extend it out another 60+ years.

That is another time stamp. It is a file time stamp, which we never store in the Git object database. The index can be revised over time since it is purely local structure. If it weren't for the need to operate with C Git in the same repo we could have used a different format, and nobody would notice. (The first jgit versions used a different index structure).

time_t is signed, but it is also 64 bit on 64-bit linux so it doesn't overflow in 2038.

$ cev 'printf("sizeof time =%d\n",sizeof(time_t));' sizeof time =8

> I'd rather just tag the fields with "2038" so we can search for
> them in the future.  Like say this:

There should be a comment on the commitTime field too if we choose that option.

-- robin