Hi Michal, On Mon, 20 Jan 2020, Michal Suchánek wrote: > On Mon, Jan 20, 2020 at 08:38:51PM +0100, Johannes Schindelin wrote: > > 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? > > Which means we can split off the timestamps to a separate file, too ;-) Sure. We could also jump from a cliff at the same time. Just because you can do something does not mean that it is a good idea to actually do it. Ciao, Johannes
