Y2038 vs struct cache_time/time_t

Team,

today, in quite an entertaining thread on Twitter (https://twitter.com/jxxf/status/1219009308438024200) I read about yet another account how the Year 2038 problem already bites people. And costs real amounts of money.

And after I stopped shaking my head in disbelief, I had a quick look, and it seems that we're safe at least until February 7th, 2106. That's not great, but I plan on not being around at that date anymore, so there. That date is when the unsigned 32-bit Unix epoch will roll over and play dead^W^Wwreak havoc (iff the human species manages to actually turn around and reverse the climate catastrophe it caused, and that's a big iff): https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs#Year_2106

Concretely, it looks as if we store our own timestamps on disk (in the index file) as uint32_t:

	/*
	 * The "cache_time" is just the low 32 bits of the
	 * time. It doesn't matter if it overflows - we only
	 * check it for equality in the 32 bits we save.
	 */
	struct cache_time {
		uint32_t sec;
		uint32_t nsec;
	};

The comment seems to indicate that we are still safe even if 2106 comes around, but I am not _quite_ that sure, as I expect us to have "greater than" checks, not only equality checks.

But wait, we're still not quite safe. If I remember correctly, 32-bit Linux still uses _signed_ 32-bit integers as `time_t`, so when we render dates, for example, and use system-provided functions, on 32-bit Linux we will at least show the wrong dates starting 2038.

This got me thinking, and I put on my QA hat. Kids, try this at home:

	$ git log --until=1.january.1960

	$ git log --since=1.january.2200

Git does not really do what you expected, eh?

Maybe we want to do something about that, and while at it also fix the overflow problems, probably requiring a new index format?

Ciao, Johannes