Re: [PATCH v4 8/9] Use uintmax_t for timestamps

> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> 
> > Previously, we used `unsigned long` for timestamps. This was only a
> > good choice on Linux, where we know implicitly that `unsigned long` is
> > what is used for `time_t`.
> >
> > However, we want to use a different data type for timestamps for two
> > reasons:
> >
> > - there is nothing that says that `unsigned long` should be the same data
> >   type as `time_t`, and indeed, on 64-bit Windows for example, it is not:
> >   `unsigned long` is 32-bit but `time_t` is 64-bit.
> >
> > - even on 32-bit Linux, where `unsigned long` (and thereby `time_t`) is
> >   32-bit, we *want* to be able to encode timestamps in Git that are
> >   currently absurdly far in the future, *even if* the system library is
> >   not able to format those timestamps into date strings.
> >
> > So let's just switch to the maximal integer type available, which should
> > be at least 64-bit for all practical purposes these days. It certainly
> > cannot be worse than `unsigned long`, so...
> 
> Should we at least clamp in date_overflows() so that large values
> representable with timestamp_t that will become unrepresentable when
> we start allowing negative timestamps would be rejected?  That way
> we won't have to hear complaints from the people who used timestamps
> far in the future that we regressed the implementation for them by
> halving the possible timestamp range.