Re: [PATCH v3] date: detect underflow/overflow when parsing dates with timezone offset
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 14, 2024, 21:02 UTC
- Message-ID
- <xmqqjzirdyqm.fsf@gitster.g>
- In-Reply-To
- <CAOLa=ZT2goTBD6WBtjYOYqa6vEsp=P=UzUBzs-5Om3d9HLZYbw@mail.gmail.com>
Karthik Nayak <karthik.188@gmail.com> writes:
Show 6 quoted lines
>> 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?
Show 12 quoted lines
>> 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.