Hi Junio, On Sun, 23 Apr 2017, Junio C Hamano wrote: > Johannes Schindelin <johannes.schindelin@xxxxxx> 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. Please note that the date_overflows() command only tests when we are about to call system functions. I do not think that it does what you think it does (namely, validate timestamps when they enter Git). Ciao, Dscho