Seems to have fixed that.

Using & is fine there, because we already create copy inside the 
method. Not using & would give us a copy of the copy in PHP4. No idea 
why that makes a difference though.

Well, my lack of understanding aside, making that change on line 254 
fixes the problems that I was able to reproduce. I've committed it to 
HEAD and FRAMEWORK_3. I'll wait to resolve this until I hear back from 
others.

Please do specify the other things you think this fixes, and the other 
places you're changing it (a full unified diff would be ideal).



I'm not sure why adding & helps here, since the whole point of 
Util::cloneObject() is to make sure that we *don't* get a reference to 
the object passed in...

I think a better way to solve this would be to add an & before 
Util::cloneObject in lib/DayView.php



on line 254 in lib/DayView.php change:

$event->start = Util::cloneObject($event->start);

to:

$event->start = &Util::cloneObject($event->start);



This change could be applied to several other instances of 
Util::cloneObject in combination with an assignment to a variable. 
This also solved a couple of strange behaviour when using Attendance 
and multiple attendants.

If needed I can specify them, just ask nicely ;)



To be honest, I can't quite get why the ampersand is needed in front 
of the function but my guess is that php4 will garbage collect the 
cloned object if you dont add the ampersand.

It looks the same as #1200, but in my case I dont have any overlapping events.

If I create a repeated event for every day, the week view already gets 
distorted.



Monthly or weekly repeated events are ok.

I use php 4.3.10 on SuSE 9.0 and debian(woody) systems.

I'll look at your proposed patch when I can, but can you check if this 
is a duplicate of #1200?

No, I don't.

I have found where my problem is:

It is a patch introduced in DayView.php version 1.139



on line 254:

$event->start = Util::cloneObject($event->start);

which was in 1.138:

$event->start = &new Horde_Date($event->start);



After I revert this single change, everything works as expected again.

My guess is that this is a bug in PHP 4.3.10 or in Util::cloneObject()

Jan, Are you using php 5? As this could explain why you did not see 
this behaviour.

No, because I have a lot of recurring events and all work fine here.

Sorry for my inclarity, here are the steps to reproduce this:



Create a recurring event  (every day) and it will show up perfectly in 
day,month,year view but not in work or workweek view. Instead it will 
only show up on the weekday it has been created.



Using shared calendars sometimes makes the behaviour worse, but this 
is hard to reproduce.



Hope this helps

This is not a very helpful bug report. Please provide exact steps how 
to reproduce this.

When you have a shared calendar and you also have recurring events,   
the recurring events are shown ok in day and month view.

But if you select the week or workweek view the recurring events 
become invisible or partly invisible or even jump to an empty row in 
the table.

So it seems the problem lies only in the week and workweek views.