Re: Patching Git to handle dates before the Unix epoch

From: Jeff King <peff@peff.net>
Date: Sep 10, 2019, 16:31 UTC
Message-ID: <20190910163117.GB12758@sigill.intra.peff.net>
In-Reply-To: <003301d567f2$03550df0$09ff29d0$@nexbridge.com>

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

Show 13 quoted lines

> 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