First, thank you everyone involved for your work on this module. My clients have been very happy to see it; even with the "beta" status.

I believe someone else mentioned this problem earlier on the forum, but their post was somewhat incoherent so I decided to start a new (hopefully coherent) thread. My hope is to solve both of our problems.

The issue at hand is that an all-day event is added, but it ends up being duplicated on either the next day, or both the next day and current day (on month view).

See the problem:
http://trisomy18support.org/modules/piCal/index.php?smode=Monthly&caldate=2004-8-18

Particularly, see item:
http://trisomy18support.org/modules/piCal/index.php?smode=Monthly&action=View&event_id=00...

and item:
http://trisomy18support.org/modules/piCal/index.php?action=View&event_id=00001964

So, this appears to be a single post on the calendar. The properties is that it recurs every year. In this case, it's an all-day event without specified date-time.

My intention is to find some modification of the PHP such that:

A) When all-day event is submitted, it doesn't duplicate the event on the original date
B) When all-day event is recurred, it doesn't span two days no matter what time-zone it is in.

This is high-priority for this site.

My initial instincts (without looking at the code) is as follows:

For A)
- I believe there is an entry in the database for each occurrence of a recurring event... correct? In which case the problem is that when a new all-day recurring event is submitted for some reason the first occurrence is slightly different than subsequent occurrences, and that the algorithm for determining the first recurrence date must be slightly out-of-whack (possibly based on differences in time-zone, eg. because the person's time-zone is slightly before server's, therefore the "next" occurance of a yearly recurring event is today at 5:00... but really, that's a problem, not an excuse).

For B)
- I don't want to play-around with the datetime string... all I want to do is modify the handler of the all-day event object (if such an object exists) such that whenever these events are analyzed they are treated strictly as single-day events.

So, again, I appreciate that this is only beta. I am quite willing to do some of the hacking myself and share the result with the community; the thing I'd really like is for someone who's worked on this to:

- give me some initial feedback on my first conclusions
- let me know if I'm barking up the right trees,
- let me know if they have a quick solution, and
- let me know where a good place to start hacking would be.

Many thanks, and I look forward to continued use of this well-constructed module. I must admit - I'll take solidarity in the module over more features any day, but your future feature set does look inviting.

Thanks in advance,
Keith

I am having the exact same problem myself. I'm not much of a hacker but will be willing to test any attempted fix.

Brewman

sorry, bad post (stupid mistake)

I'm sorry, I've had an aweful day trying to hack this thing. I upgraded to .6, but didn't read the advice on updating tables and unsuccessfully tried to do it myself. Anyways, everything's back up now; all events are still there; version is .6, BUT, I'm still experiencing the exact same date problems (A and B) described earlier.

Sooooo... I can only ask once again for advice on fixing the origional problem.

Thanks,
Keith

hi kjs222

It looks like allday flag lost.
I didn't read all of your post, the events displayed wrong datetime are perhaps caused by your careless hack or your wrong setting.
Since I know "allday flag" has a big importance, I never write the codes like that the allday events are displayed with time.

Hi GIJOE,

My piCal is not hacked; and I don't know what setting you are talking about.

So, neither of us hacked the piCal, but both of us have the same issues; the ones that are outlined in my post.

Are you saying that you don't know how to fix the module?

Please help us fix it.

Keith

FYI, I have chosen to pursue this difficulty on xoops.org.

Cheers,
Keith

Please see thread for fix.

Also note that this fix needs implemented on recurrances other than yearly (my fix only works for yearly).

Quote:Don't you think it is impolite ?
All codes of piCal is mine. (without iCal_parser)

Nobody can fix "not a bug".
If you think a bug, show the examples with "TERSE" caption.

I'm very busy and hard to communicate in English because my mother tongue is not English.
So I have no free time to read "PROLIX" sentences.

Hi GIJOE,

I am sorry if I sounded rude. I had waited two days for an answer and you said you did not read my post - I felt very hurt.

Unfortunately it was a bug - I am sorry if there was a communication problem; I don't know what "TERSE" and "PROLIX" are.

My bug report is on xoops.org (see other post for link). A more full report is this:

In "function rrule_extract( $event_id )"

Change all:

$duration = $event->end - $event->start ;

to:

if ($event->allday) $duration=1;
else $duration = $event->end - $event->start ;

This makes sure all-day event does not overlap to second day.

Also in

sorry, I continue to have problems with posts cut-off.

(Continuation)
in same function, Change all

if( $start <= $event->start) continue;

to:

if( $start <= $event->start + 150000) continue;

[continuation]

This makes sure that the first day is not duplicated on all day events when recurring. I am not sure about the number 150000, but I think it is OK.

So, again, I am sorry for being rude. I hope that this bug report is good enough for you.

Cheers,
Keith

hi kjs222.
Quote:The meaning of this code is understandable for me.
Probably doublizing events in same month will occur with some conditions.

But I want to know not a hack code but a the condition.
eg) why 150000?
a event - Weekly, all monday&Tuesday a week - will fail to rrule_extraction if event start from monday.

I tried to reproduce the conditions doublizing events in same month, but I can't.

Tell me the condition that the bug acturalize.

1) Server Timezone
2) Your Timezone set in XOOPS
3) Event Timezone
4) start&end datetime
5) allday or not
6) RRULE Pattern

All of these 6 conditions are important.

Quote:I can't understand the meaning of this code.
All of allday events has its length.
It's integral multiples of 86400.

If some allday events whose length is only a day are displayed separated two days,
tell me the conditions of the events.

Of course, 6 conditions which I have mentioned are necessary.

The most ordinary reason why some allday events are displayed separatly is that the server timezone has been changed. (or setting of server Timezone in XOOPS has been changed or has been wrong)

First of all, try to modify the allday event right now.

hi Keith.
It must be caused by summer time.

You should set your server timezone using no summer time, I think.

Hi GIJOE,

I think you are right. That is understandable. But I can not access summertime setting for my server.

For me,

Server time: -5
Xoops time: -5
Xoops User Time: -5

Maybe you add a handler for summertime server? It seems like this is a common problem; now that piCal is in English ~ maybe the problem is not in Asia?

Thank you; I appreciate your help,

Keith

15000 was a random number; it should be 86400 (as you say).

Again, this is a summertime server problem. This event is in August. This event is the event that has both problems.

id = 2522
sequence = 2 ,
tzid = -5 ,
dtstamp = 2.00401E+13 ,
class = PUBLIC ,
rrule = FREQ=YEARLY;INTERVAL=1;BYMONTH=8;WKST=SU ,
rrule_pid = 2522 ,
unique_id = pical040-5adcc6864924334eade680ccc3cd3f02 ,
allday = 1 ,
start = 1092715200 ,
end = 1092801600 ,
start_date = NULL ,
end_date = NULL ,
server_tz = -5 ,
poster_tz = -5 ,

Thanks,
Keith

hi Keith.

Thank you the important information.
And more a query... tell me your Timezone's name.
(not numeric but string)

I'll check later.

Quote:Hmmm...
I think all of server should not use summer time though its country or state uses summer time, because the time is a absolute standard for server's user.

eg) If the server is placed in Los Angels, the timezone should be Etc/GMT+8, not America/Los_Angels.

Probably some countries in Asia use summer time, but the servers in the countries should not use summer time, I insist strongly.

But there are many servers that has wrong timezones in the world.
This is an undoubtful fact.

I have to support such servers, though I don't feel like it...

I am sorry for my bad server. I hope the fix is not too hard.

I look forward to seeing the fix; thank you again for your help.

Keith

I'll add an option store timestamps of events as GMT.
This will solve the problem.

Hi GIJOE,

I just reviewed your new release; looks good - I understand from your TODO that the addition of summer time servers has not been implemented? If there's something I can do to help with that let me know; I don't know if it's something I'm capable of, but if you give me some guidance I'll try.

Look forward to seeing those partnerships with eguide and weblog.

Thanks,
Keith

hi Keith.

Wait a little bit longer till the problem with summer time will be solved.
Because I don't know the environment with summer time at all, I'm hard to code it.

Perhaps cooperation with another modules is much easier than summer time problem, I think.