Re: [bugs] [PATCH] Check for the year span 1902-2037.

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.

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'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
stop.

> 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.

Lars Henriksen

Links