Welcome Guest   | Login   
  Search  
  Index |  Recent Threads |  Register | 


Quick Go »
Thread Status: Normal
Total posts in this thread: 2
[Change thread status] [Delete this Thread] [Move this Thread]
[Add To My Favorites] [Watch this Thread] [Post new Thread]
Author
Previous Thread This topic has been viewed 87 times and has 1 reply Next Thread
bdperkin
New Member



Joined: Jan 2, 2014
Posts: 1
Status: Offline

Edit this Post   Recurring all day events in iCal format should end on correct day of month and not include time in RRULE Reply to this Post
Reply with Quote
[Delete this Thread]

Apologies if this is documented somewhere, but I have literally spent hours looking for an answer to this or workaround, but I'm more and more convinced it's a bug. As a result, I'm going to write this post as a bug report more than a general thread.

Description of problem:
Recurring all day events in iCal format should end on correct day of month and not include time in RRULE

Version-Release number of selected component:
Whatever version of code that was running on Thu Jan 2 19:00:00 UTC 2014

How reproducible:
Always

Steps to Reproduce:
1. Login and navigate to http://www.localendar.com/elsie
2. Click on "Add Event" from the local navigation on the left.
3. Enter an event title in the "Title" text field. For example: "Test 00".
4. Select the "All Day Event" radio button in the "Time" input field.
5. Expand the "This event repeats" section.
6. Select the "Repeat Daily (until date above)" radio button.
7. Modify the "Repeat Until" drop-down to be some date in the future. For example: "January 1 2014".
8. Press the "Save" button.
9. Test 1: View public web interface: http://www.localendar.com/public/[username]
10. Test 2: View "RRULE" field of event created: curl -s http://www.localendar.com/public/[username]?style=X2 | grep ^RRULE

Actual results:
Test 1: Repeated event matches specification
Test 2: The "UNTIL" attribute of the RRULE field is an additional day out (02 instead of 01, in this case) and includes a time:
$ curl -s http://www.localendar.com/public/bdperkin?style=X2 | grep ^RRULE
RRULE:FREQ=WEEKLY;UNTIL=20140102T190000Z;BYDAY=SU,MO,TU,WE,TH,FR,SA

Expected results:
Test 1: Repeated event matches specification
Test 2: The "UNTIL" attribute of the RRULE field is the expected end day and does NOT include a time:
$ curl -s http://www.localendar.com/public/bdperkin?style=X2 | grep ^RRULE
RRULE:FREQ=WEEKLY;UNTIL=20140101;BYDAY=SU,MO,TU,WE,TH,FR,SA

Additional info:
This was found while using a public calendar as a URL through Google Calendar. The repeated all-day events result in appearing as running one additional day in Google Calendar. Manually modifying the ics and importing it works, therefore, I believe that if this change is made on localendar server-side, this fix should "just work".
[Jan 2, 2014, 7:30:59 PM] [66.187.233.202] Show Post Printable Version [Link] Report threatening post: please login first  Go to top 
support
localendar Expert
Member's Avatar


Joined: Aug 9, 2022
Posts: 6395
Status: Offline
Edit this Post   Re: Recurring all day events in iCal format should end on correct day of month and not include time in RRULE Reply to this Post
Reply with Quote
[Delete this Post]

In supporting iCal, we've tried testing with as many firms as possible, including Apple, Google, Yahoo, Microsoft (Outlook) and others.

The spec for the iCal RRULE is clear:
The UNTIL rule part defines a date-time value which bounds the recurrence rule in an inclusive manner
http://www.ietf.org/rfc/rfc2445.txt
(emphasis mine)

Your example bug actually parses fine in Outlook, for example. In general, the spec encourages as much specificity as possible, and does not want to leave Date parsing open to implementation (which is what happens when you leave out a time). Unfortunately, Google isn't perfect smile They've decided to only support 1 possible format. Again, excerpted from the spec:
"...this date or date-time becomes the last instance of the recurrence" (emphasis mine again)

We will look at the latest version of the products we test with and see if they can "get by" with the more minimal specification. After all, Google is popular and we are feel compelled to work with them, even if they don't have the best implementation.
----------------------------------------
Marc Higgins
Support Associate, localendar.com
Follow us on Twitter! http://www.twitter.com/localendar_news
[Jan 2, 2014, 9:20:06 PM] [24.189.166.34] Show Post Printable Version [Link] Report threatening post: please login first  Go to top 
[Show Thread Printable Version] [Post new Thread]

Help! | Cobranding | Legal | Privacy Policy | About localendar.com | Contact Us