Re: [bugs] [PATCH] Check for the year span 1902-2037.
- Date: Tue, 28 Nov 2017 07:27:50 +0100
- From: Lukas Fleischer <lfleischer@xxxxxxxxxxxx>
- Subject: Re: [bugs] [PATCH] Check for the year span 1902-2037.
On Mon, 27 Nov 2017 at 11:21:10, Lars Henriksen wrote:
> On Thu, Nov 23, 2017 at 08:55:12AM +0100, Lukas Fleischer wrote:
> > On Sun, 19 Nov 2017 at 22:51:57, Lars Henriksen wrote:
> > > Reintroduce year check for systems with a 32-bit time_t type.
> > > Remove the lower limit (1902) for systems with a 64-bit time_t.
> > > This limits movements in the calendar (for 32-bit systems) and in no way
> > > ensures constistency of data.
> > I agree with the patch, I am curious about what you mean by "limits
> > movements in the calendar (for 32-bit systems)", though...
> Well, that remark may seem superfluous considering the 32-bit constraint.
> What I wanted to stress is the following. The patch has two parts: the
> check of calendar moves (in ui_calendar_move()) and the check of date validity
> in check_date(). The latter is a necesssary (but not sufficient) part of
> ensuring data consistency.
> The former (move check) also involves checking the result of date_change(),
> which is really the result of mktime(). From the source files and from
> searches on the net, I can see that mktime() in the past has been somewhat
> unreliable. My own experience with a 12 year old Linux system confirms that.
> Hopefully it is no longer the case; calcurse relies heavily on mktime().
> The check on calendar moves tries to prevent unexpected results from mktime()
> and from "time wrap around" due to integer overflow. This is the limit I had
> in mind.
Okay, thanks for the clarification.
> I also had a future usage of the patch in mind. With 64-bit time the year
> span becomes so ridiculously large that it may be desirable to narrow it
> explicitly. The existing check is easily modified to accomodate any limit.
> Have you any idea how common 32-bit time still is? I really must make the
> effort and get my system updated.
I think there is still a non-negligible amount of 32-bit systems
around but I do not have any numbers...
> > I'd appreciate if you could drop the period from the subject line
> I'll try to remember, but from old habit my sentences usually end with a full
It might be better to think of the subject line as a heading to the
commit message body (or to the commit itself). Headings usually do not
end in a period.
> > and sign-off future patches :)
> That's a conscious decision on my part so I'm afraid not. You are perfectly
> welcome to do with my contributions as you like: use them, change them or
> ignore them. I don't mind either way. You have been the maintainer for many
> years and decide what goes in and how. That is as it should be, no criticism
> meant. So yours is the honour and the blame.
Ultimately, it is your decision, but I really do not see why somebody
willing to contribute to a project would deliberately refuse to add a
line which basically states "I certify that I created this patch on my
own and that my work can be licensed under the project's Open Source
license" (unless he plans on taking legal against the project later
which I do not assume)...