On Fri, Dec 03, 2021 at 05:24:03PM -0500, Taylor Blau wrote: > On Thu, Dec 02, 2021 at 10:06:07AM -0500, Derrick Stolee wrote: > - A table of 4-byte unsigned integers in network order. The ith > value is the modification time (mtime) of the ith object in the > corresponding pack by lexicographic (index) order. The mtimes > count standard epoch seconds. > > > Storing these mtimes in 32-bits means we will hit the 2038 problem. > > The commit-graph stores commit times with an extra two bits to extend > > the lifetime by another hundred years or so. > > > > Could we extend the lifetime of cruft packs by decreasing the granularity > > here? Should 'mtime' store a number of _minutes_ instead of seconds? That > > should be enough granularity for these purposes. > > Perhaps, though it does add some complexity to the code that deals with > this format at the expense of some future-proofing. I'm open to it, > though. I still have quite a bit of review from this topic sitting in my inbox. But this had been lingering on my mind, and I realized I said something incorrect. 32-bit mtimes won't cause us to run into the "2038" problem, since these aren't signed values. So storing epoch seconds in a uint32_t should get us into the year 2106. If anybody is still using cruft packs by then, I'll call this project a wild success ;-). So in the meantime, I don't think it makes sense to reduce the granularity and/or use extra bits to store the timestamps. Thanks, Taylor
