On September 10, 2019 10:15 AM, Diomidis Spinellis wrote: > As people use Git to create synthetic commits of code written in the past > [1,2] it becomes important to handle dates before the Unix epoch > (1/1/1970). I see that modern C libraries, Unix kernels, and tools can handle > such dates. However Git seems to mishandle such dates in several places, > such as in date.c [3,4]. I'm planning to work on a fix, but before I embark on > this I have a few questions. > > - Do you see any reasons that may prevent the acceptance of such a patch? > - Can you think of any non-obvious issues (e.g. backward compatibility, > switch to the Gregorian calendar) I should be aware of? > - Should I submit changes as a bug fix on the maint branch or as a new > feature on master? My suggestion is a new feature as a patch. See other contributions. While you're at this, especially given how extensive this may be given the time_t references, it might be useful to examine the end of epoch concerns as well. 2036 is not that far off and some of the repositories I am managing will likely last beyond the Unix date rollover. There are no time64_t to get us to 2106, but even that is probably not sufficient (thinking beyond my own expiry date). The concept of unlimited date ranges is intriguing if we are going to store broader range artifacts in git, like signatures of physical core samples and use the carbon dating in git, or some Sci-Fi conceptual commit on old 1701D. So if I had a preference, it would be to store an extensible date range going from the Big Bang to the Big Crunch (or beyond), but that is excessive. Sadly my platform's own date ranges are 64-bit microsecond that range from year 1 (AD) - 10000 (AD) and I can't map easily to Unix dates. Just my $0.02, Randall
