Last week, I quietly rolled out a new release (r188 or the “return of metallica“) to MTB Calendar, but alas it didn’t turn out exactly as planned. Although many of the new features are fine, it appears that we have a slight bug … err … regression in the iCal department. For those of you who have subscribed to a iCal feed, I changed the formatting to more closely follow the iCal standard (RFC 2445). This says (paraphrasing here) that you make all day events from 12AM on the date of start to 12AM on the date of end (exclusive).

So I made that change.

Unfortunately, Apple’s iCal does not share my interpretation — it converted the all day events to timed ones (which ran from 24 hours from 12AM to 12AM the next day). Since I hate this, I’ve rolled back this change.

It gets geeky here.

My problem was that I wasn’t passing the correct property parameter for the DTSTART or DTEND properties that iCal, Google Calendar and everyone seems to want. Google shows it best:

SUMMARY:Independence Day

Digging into the icalendar gem documentation, I found the correct way to do this (see the event.dtstart line):

  def to_ical_event
    # the alldayevent sets up the parameter
    alldayevent = {"VALUE" =>["DATE"]}
    event =
    event.klass       "PUBLIC"
    # add the alldayevent to end of dtstart,dtend
    event.dtstart     start_date.to_date, alldayevent
    event.dtend       end_date.tomorrow.to_date, alldayevent
    event.summary     name
    event.description description.gsub(/\s+$/, $/) unless description.nil?
    event.location    location.gsub(/\s+$/, $/) unless location.nil?
    event.dtstamp     created_at.to_datetime
    event.url         "{}"
    event.uid         "mtb-event-#{}"
    return event

Net/net: you should know be able to use the ical feeds in iCal, Google Calendar or anywhere else you please. Look for easy add buttons for Google Calendar and Outlook to come soon.

Tags: , , ,

blog comments powered by Disqus