onsdag 17 december 2008 23:48:44 skrev Shawn O. Pearce:
> Robin Rosenberg <robin.rosenberg@xxxxxxxxxx> 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.
> 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
--
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
