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
