Junio C Hamano <gitster@xxxxxxxxx> writes: > Phillip Wood <phillip.wood123@xxxxxxxxx> writes: > >>>> +/* timestamp of 2099-12-31T23:59:59Z, including 32 leap days */ >>>> +static const time_t timestamp_max = ((2100L - 1970) * 365 + 32) * 24 * 60 * 60 - 1; >>>> >>> Nit: but since we're calculating the number of years here (2100L - >>> 1970), shouldn't we also be calculating the number of leap days instead >>> of hardcoding it? >> >> I'm happy with a hard coded constant for the number of leap days - I >> think it is probably easier to check that (which I have done) than it >> would be to check the calculation as I'm not sure off the top of my >> head if is it safe to do (2100-1970)/4 or whether we need something >> more complicated. > > 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. > 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.
Attachment:
signature.asc
Description: PGP signature
