recurring events with start dates before 1970 not showing

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Have events synchronized from CalDAV server that are before 1970 (e.g. date 
of birth)
    They get into the database.
2. View a month (todo) where this event reoccurs (some persons birthday)

What is the expected output? What do you see instead?
The event (birthday) is missing.

What version of the product are you using? On what operating system?
roundcube 0.8-rc, latest calendar plugin, sqlite database.

Please provide any additional information below.
Those events DO get synchronized into the roundcube sqlite database.  But 
start/end times are in UNIX epoch format and so they are negative integers. E.g.

sqlite> select * from events_caldav where start<0;
includes (modified) output:
48|37604a1e-37a3-4145-bb6c-caba2fba268e|0|0|1|-42771600|-42685260|2145830400|y|3
1536000|0|0|0|0|some person. Geburtstag|||my 
calendar||a:3:{i:0;s:36:"37604a1e-37a3-4145-bb6c-caba2fba268e";i:1;b:0;i:2;s:1:"
*";}|https://dav.server/url/|0|0|0|0|0|0|1|0

Original issue reported on code.google.com by Lutz.Pre...@gmail.com on 18 Aug 2012 at 4:48

[GoogleCodeExporter]

I won't fix it. There a quite good reasons not to do it. The recurring event 
part of the plugin won't go back to dates before 1970. Some of the next 
releases won't even go back before 1990. Store your birthday events with a 
recent year and put the birth year into the summary or description.

Original comment by rol...@liebl.ath.cx on 18 Aug 2012 at 4:58

• Changed state: WontFix

[GoogleCodeExporter]

What are the "quite good reasons"? Performance in some way? Even then it may be 
an option. Honestly, your proposition is not the way synchronized platform 
independent calendaring data are intended. Other platforms have no problem with 
this data (android phone, iCal, ...).

THanks a lot for your work anyway!

Original comment by Lutz.Pre...@gmail.com on 18 Aug 2012 at 5:07

[GoogleCodeExporter]

Yes it is performance. May be the code is not the best. But it is as it is. The 
current code requires the initial event to create recurring events. I really 
don't want to go back so far to pick up initial events and then to create the 
recurring clones. Sorry about inconvience, but it is as it is and I won't 
change it.

Original comment by rol...@liebl.ath.cx on 18 Aug 2012 at 6:49

[GoogleCodeExporter]

I understand the problem. I've looked into the code, and even if I don't 
understand the structure fully and first experiments have not been sufficiant, 
I see that recurring events are cloned from 1970 to 2029 currently. Correct? 
The problem is the clones and memory use, not searching all events for 
recurring ones, isn't it?
Maybe one could create the cloned events only within the selected replication 
interval but interprete each event?

I will try to do some tests/changes (even not doing much PHP), could you tell 
me where 1970 (=0) would have to be changed. I looked for all places CALEOT is 
used.

Original comment by Lutz.Pre...@gmail.com on 18 Aug 2012 at 7:01

[GoogleCodeExporter]

Fixed in calendar 9.8.1. I'm not sure if I'll keep this change. Let's see if we 
run in memory exhaustion issues again.

Original comment by rol...@liebl.ath.cx on 22 Aug 2012 at 6:15

• Changed state: Fixed

[GoogleCodeExporter]

This is great, thanks a lot! I have a problem though: (after roundcube upgrade 
from 0.8rc to 0.8.1 - and plugin_manager, calendar plugins) I now ONLY see 
recurring events in the calendar views (including the missing birthdays 
previously). This happens even after delete all categories and connecting to a 
calendar with only some simple events. They are synced into the database, and I 
can search for them in the search field (!), but not shown in the calendar 
views (no filter set). Any idea? I know, this probably should be a new bug. Lutz

Original comment by Lutz.Pre...@gmail.com on 22 Aug 2012 at 3:53

[GoogleCodeExporter]

Please try to reproduce the issue @ mail4us.net.

#1- Register
#2- Set up your CalDavs
#3- Mail me the credentials of the test account (myrounducbe at mail4us dot net)

Original comment by rol...@liebl.ath.cx on 22 Aug 2012 at 6:41