Karthik Nayak <karthik.188@xxxxxxxxx> writes: >> It's even OK to use a hard coded constant for the number of days >> since the epoch to the git-end-of-time ;-) > > That's why I noted it as a _Nit_, mostly because it wasn't anything big. > But I found that part of it being dynamic and part of it being static > was inconsistent. Sure, but it is so tiny thing, we shouldn't waste more time than we spend getting the tests right even on 32-bit systems. We seem to be doing the opposite by talking about this part even more, which is a bit sad. Any comments on the actual patch I sent as a follow-up? >> The timestamp of the git-end-of-time would not fit in time_t on >> 32-bit systems, I would presume? If our tests are trying to see if >> timestamps around the beginning of year 2100 are handled >> "correctly", the definition of the correctness needs to be >> consitional on the platform. >> >> On systems with TIME_T_IS_64BIT, we'd want to see such a timestamp >> to be represented fine. On systems without, we'd want to see the >> "Timestamp too large for this system" error when we feed such a >> timestamp to be parsed. >> >> Thanks.
