Re: Patching Git to handle dates before the Unix epoch

[Jeff King <peff@peff.net>]

On Tue, Sep 10, 2019 at 12:08:34PM -0400, Randall S. Becker wrote:

> 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.

Internally we now use a uintmax_t (with a resolution of 1-second) for
parsing and storing most timestamps, which should presumably be at least
64-bit on most systems. We do convert to time_t at various points,
recognizing truncation and switching that to a sentinel value (so at
least you get "Jan 1 1970" instead of some random wrapped time).

So I think we should behave sanely in all cases (at least going forward
from 1970 for now), and it's a quality-of-implementation issue whether
any given system can pretty-print specific dates.

Switching that to intmax_t should get us pretty good coverage in the
opposite direction, and anybody with a 64-bit signed time_t on their
system will generally be happy.

-Peff