Hi Junio, On Mon, 24 Apr 2017, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > >> 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). > > OK, then please read my question without date_overflows(), that is, > "should we at least clamp the values with some new mechanism to leave > the door open for supporting times before the epoch, even if (and > especially if) we leave the use of signed integral type for timestamps > out of the scope of this series?" You are asking the wrong person because I do not care about timestamps dating before the dawn of Unix. In any case, it is a question unrelated to the work I performed in this patch series: the raison d'être of these patches is to allow timestamps to refer to dates that are currently insanely far in the future. Ciao, Dscho