I'm using America/New_York on both servers. You might be on to something with the TZ parsing because if I edit the event through CalDAVZap to have the recurring event end on 30 July, I get an event displaying for 29 July, but not on the 30th. I think this takes the VEVENT data and author out of the mix.
I can't easily give you an account on the production server. I can give you access to my home test server, but it works fine there.
On 07/25/2013 09:52 AM, Andrej Lezo wrote:
Hello Ken, You're right, this is not a problem with event parsing. One thing which comes to my mind is something wrong with timezone processing. Which Time zone have you selected on your test and production versions (bottom left corner)? If that won't help, you could create an account for us. Regards, Andrej Lezo Dňa 25. 7. 2013 15:17 Ken Murchison wrote / napísal(a):
I can look but wouldn't that cause the entire event to not display, as opposed to just the final recurrence not displaying?
On 07/25/2013 09:10 AM, Ján Máté wrote:
are you sure that there are no invisible characters in the vEvent definition on your production server?
p.s.: rc2 is the latest public release
On Jul 25, 2013, at 1:40 PM, Ken Murchison email@example.com wrote:
Hmm. It displays fine on my home test server, but not on our production server. Both servers are running 0.9.1rc2. Is there a later version? I tried with multiple browsers and still nothing displays on 29 July on our production server. I tried running cache_update.sh and flushing the browser cache as well. Any ideas?
On 07/25/2013 04:02 AM, Andrej Lezo wrote:
Hello Ken, I checked your recurring event on our latest versions - demo version (http://www.inf-it.com/caldavzap/) and latest rc version and it didn't seem that there are some problem. I can see event on 29/7 correctly. Which version of CalDAVZap are you using? You can try update on latest version. Thank you for using our software. Regards, Andrej Lezo Dňa 23. 7. 2013 15:27 Ken Murchison wrote / napísal(a):
I have the recurring event show below, which properly displays the event on 7/29 in the Apple clients, Thunderbird, and Google's web app, but CalDAVZap doesn't show an event on 7/29.
BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Apple Inc.//Mac OS X 10.8.4//EN CALSCALE:GREGORIAN BEGIN:VTIMEZONE TZID:America/New_York BEGIN:DAYLIGHT TZOFFSETFROM:-0500 RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3 DTSTART:20070311T020000 TZNAME:EDT TZOFFSETTO:-0400 END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11 DTSTART:20071104T020000 TZNAME:EST TZOFFSETTO:-0500 END:STANDARD END:VTIMEZONE BEGIN:VEVENT TRANSP:OPAQUE DTEND;TZID=America/New_York:20130708T100000 UID:firstname.lastname@example.org DTSTAMP:20130718T182134Z STATUS:CONFIRMED SEQUENCE:0 SUMMARY:Driver Ed LAST-MODIFIED:20130602T123428Z DTSTART;TZID=America/New_York:20130708T070000 CREATED:20130602T123428Z RRULE:FREQ=WEEKLY;UNTIL=20130729T110000Z;BYDAY=MO,TU,WE,TH,FR BEGIN:VALARM X-WR-ALARMUID:692B65FB-C722-47C6-9C27-E8F071D1C64C UID:692B65FB-C722-47C6-9C27-E8F071D1C64C TRIGGER;VALUE=DATE-TIME:19760401T005545Z X-APPLE-DEFAULT-ALARM:TRUE ACTION:NONE END:VALARM END:VEVENT END:VCALENDAR
-- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University