• Fix bug caused by limiting count on add_instances.
• Various refactorings.

• Optimize for case of large number of instances
• Refactor to silence deprecation warnings

• Handle case where count is less than zero. This would cause ArgumentError: negative array size

• Add detection of unbounded component in RiCal::Calendar#occurrences. This prevents us from entering into an endless loop.

• Added the RiCal::Calendar#occurrences method to return all occurrences for the calendar taking recurring event instances into account. These events have the same id as the parent event and have recurrence_id set to the original dtstart of the event in the recurrence.

  RiCal::Calendar#occurrences takes the same options as RiCal::Event#occurrences with the same behavior.

RubyGems NOT YET

by Jon Phenow Forked from https://github.com/rubyredrick/ri_cal

I (Jon Phenow) have only recently forked this and am in the process of cleaning and rewriting. Please be aware that some of this README may be out of date.

A new Ruby implementation of RFC2445 iCalendar.

The existing Ruby iCalendar libraries (e.g. icalendar, vpim) provide for parsing and generating icalendar files, but do not support important things like enumerating occurrences of repeating events.

This is a clean-slate implementation of RFC2445.

A Google group for discussion of this library has been set up http://groups.google.com/group/rical_gem

• All examples of recurring events in RFC 2445 are handled. RSpec examples are provided for them.

An iCalendar calendar comprises subcomponents like Events, Timezones and Todos. Each component may have properties, for example an event has a dtstart property which defines the time (and date) on which the event starts.

RiCal components will provide reasonable ruby objects as the values of these properties, and allow the properties to be set to ruby objects which are reasonable for the particular property. For example time properties like dtstart can be set to a ruby Time, DateTime or Date object, and will return a DateTime or Date object when queried.

The methods for accessing the properties of each type of component are defined in a module with the same name as the component class in the RiCal::properties module. For example the property accessing methods for RiCal::Component::Event are defined in RiCal::Properties::Event

RiCal provides a builder DSL for creating calendars and calendar components. An example

RiCal.Calendar do
  event do
    description "MA-6 First US Manned Spaceflight"
      dtstart     DateTime.parse("2/20/1962 14:47:39")
      dtend       DateTime.parse("2/20/1962 19:43:02")
      location    "Cape Canaveral"
      add_attendee "[email protected]"
      alarm do
      description "Segment 51"
    end
  end
end

This style is for compatibility with the iCalendar and vpim to ease migration. The downside is that the block is evaluated in the context of a different object which can cause surprises if the block contains direct instance variable references or implicit references to self. Note that, in this style, one must use 'declarative' method calls like dtstart to set values rather than more natural attribute writer methods, like dtstart=

Alternatively you can pass a block with a single argument, in this case the component being built will be passed as that argument

RiCal.Calendar do |cal|
  cal.event do |event|
    event.description = "MA-6 First US Manned Spaceflight"
    event.dtstart =  DateTime.parse("2/20/1962 14:47:39")
    event.dtend = DateTime.parse("2/20/1962 19:43:02")
    event.location = "Cape Canaveral"
    event.add_attendee "[email protected]"
    event.alarm do
      description "Segment 51"
    end
  end
end

As the example shows, the two styles can be mixed, the inner block which builds the alarm uses the first style.

The blocks are evaluated in the context of an object which builds the calendar or calendar component. method names starting with add_ or remove_ are sent to the component, method names which correspond to a property value setter of the object being built will cause that setter to be sent to the component with the provided value.

A method corresponding to the name of one of the components sub component will create the sub component and evaluate a block if given in the context of the new subcomponent.

Certain RFC Components have properties which may be specified multiple times, for example, an Event may have zero or more comment properties, A component will have a family of methods for building/manipulating such a property, e.g.

Event#comment           # will return an array of comment strings.
Event#comment=          # takes a single comment string and gives the event a single comment property, replacing any existing comment property collection.
Event#comments=         # takes multiple comment string arguments and gives the event a comment property for each, replacing any existing comment property collection.
Event#add_comment       # takes a single comment string argument and adds a comment property.
Event#add_comments      # takes multiple comment string arguments and adds a comment property for each.
Event#remove_comment    # takes a single comment string argument and removes an existing comment property with that value.
Event#remove_comments   # takes multiple comment string argument and removes an existing comment property with that value.

RFC2445 describes three different kinds of DATE-TIME values with respect to time zones:

1. date-times with a local time. These have no actual time zone, instead they are to be interpreted in the local time zone of the viewer. These floating times are used for things like the New Years celebration which is observed at local midnight whether you happen to be in Paris, London, or New York.

2. date-times with UTC time. An application would either display these with an indication of the time zone, or convert them to the viewer's time zone, perhaps depending on user settings.

3. date-times with a specified time zone.

RiCal can be given ruby Time, DateTime, or Date objects for the value of properties requiring an iCalendar DATE-TIME value. It can also be given a string

Note that a date only DATE-TIME value has no time zone by definition, effectively such values float and describe a date as viewed by the user in his/her local time zone.

When a Ruby Time or DateTime instance is used to set properties with with a DATE-TIME value, it needs to determine which of the three types it represents. RiCal is designed to make use of the TimeWithZone support which has been part of the ActiveSupport component of Ruby on Rails since Rails 2.2. However it's been carefully designed not to require Rails or ActiveSupport, but to dynamically detect the presence of the TimeWithZone support.

RiCal adds accessor methods for a tzid attribute to the Ruby Time, and DateTime classes as well as a set_tzid method which sets the tzid attribute and returns the receiver for convenience in building calendars. If ActiveSupport::TimeWithZone is defined, a tzid instance method is defined which returns the identifier of the time zone.

When the value of a DATE-TIME property is set to a value, the following processing occurs:

• If the value is a string, then it must be a valid rfc 2445 date or datetime string optionally preceded by a parameter specification e.g

20010911 will be interpreted as a date

20090530T123000Z will be interpreted as the time May 30, 2009 at 12:30:00 UTC

20090530T123000 will be interpreted as the time May 30, 2009 with a floating time zone

TZID=America/New_York:20090530T123000 will be interpreted as the time May 30, 2009 in the time zone identified by "America/New_York"

• If the value is a Date it will be interpreted as that date
• If the value is a Time, DateTime, or TimeWithZone then the tzid attribute will determine the time zone. If tzid returns nil then the default tzid will be used.

The PropertyValue::DateTime class has a default_tzid attribute which is initialized to "UTC".

The Component::Calendar class also has a default_tzid attribute, which may be set, but if it is not set the default_tzid of the PropertyValue::DateTime class will be used.

To set the interpreting of Times and DateTimes which have no tzid as floating times, set the default_tzid for Component::Calendar and/or PropertyValue::DateTime to :floating.

Also note that time zone identifiers are not standardized by RFC 2445. For an RiCal originated calendar time zone identifiers recognized by the TZInfo gem, or the TZInfo implementation provided by ActiveSupport as the case may be may be used. The valid time zone identifiers for a non-RiCal generated calendar imported into RiCalendar are determined by the VTIMEZONE compoents within the imported calendar.

If you use a timezone identifer within a calendar which is not defined within the calendar it will detected at the time you try to convert a timezone. In this case an InvalidTimezoneIdentifier error will be raised by the conversion method.

To explicitly set a floating time you can use the method #with_floating_timezone on Time or DateTime instances as in

event.dtstart = Time.parse("1/1/2010 00:00:00").with_floating_timezone

or the equivalent

event.dtstart = Time.parse("1/1/2010 00:00:00").set_tzid(:floating)

Calendars created by the RiCal Builder DSL use TZInfo as a source of time zone definition information. RFC 2445 does not specify standard names for time zones, so each time zone identifier (tzid) within an icalendar data stream must correspond to a VTIMEZONE component in that data stream.

When an RiCal calendar is exported to an icalendar data stream, the needed VTIMEZONE components will be generated. In addition a parameter is added to the PRODID property of the calendar which identifies that the source of tzids is tzinfo. For purposes of this documentation such a calendar is called a tzinfo calendar.

When RiCal imports an icalendar data stream produced by another library or application, such as Apple's ical.app, or Google mail, it will be recognized as not being a non-tzinfo calendar, and any tzids will be resolved using the included VTIMEZONEs. Note that these calendars may well use tzids which are not recognizable by the tzinfo gem or by the similar code provided by ActiveSupport, so care is needed in using them.

The result of accessing the value of a DATETIME property (e.g. event.dtstart) depends on several factors:

• If the property has a DATE value, then the result will be a Ruby Date object.

• Otherwise, if the property has a DATETIME value with a floating timezone, then the result will be a Ruby DateTime object, the tzid attribute will be set to :floating, and will respond truthily to has_floating_timezone?

• Otherwise if the value is attached to a property contained in a non-tzinfo calendar, or if the ActiveSupport gem is not loaded, then the result will be a Ruby DateTime object, with the proper offset from UTC, and with the tzid property set.

• Finally, if the value is attached to a property contained in a tzinfo calendar and the ActiveSupport gem is loaded, then the result will be an ActiveSupport::TimeWithZone with the proper tzid.

A calendar component which supports recurrence properties (e.g. Event) may have zero or more RDATE and or EXDATE properties. Each RDATE/EXDATE property in turn specifies one or more occurrences to be either added to or removed from the component's recurrence list. Each element of the list may be either a DATE, a DATETIME, or a PERIOD, or the RFC 2445 string representation of one of these:

event.rdate = "20090305"
event.rdate = "20090305T120000"
event.rdate = "20090305T120000/P1H30M"

It can also have multiple occurrences, specified as multiple parameters:

event.rdate = "20090305T120000", "20090405T120000"
event.rdate = DateTime.parse("12 December, 2005 3:00 pm"), DateTime.civil(2001, 3, 4, 15, 30, 0)

Multiple string values can be combined separated by commas:

event.rdate = "20090305T120000,20090405T120000"

An occurrence list has one set of parameters, so only one timezone can be used, the timezone may be set explicitly via the first argument. If the first argument is a string, it is first split on commas. Then if the first segment (up to the first comma if any) is not a valid RFC 2445 representation of a DATE, DATETIME, or PERIOD, then it will be used as the timezone for the occurrence list. Otherwise the arguments must have the same time zone or an InvalidPropertyValue error will be raised.

RiCal can parse icalendar data from either a string or a Ruby io object.

The data may consist of one or more icalendar calendars, or one or more icalendar components (e.g. one or more VEVENT, or VTODO objects.)

In either case the result will be an array of components.

RiCal.parse_string <<ENDCAL
BEGIN:VCALENDAR
X-WR-TIMEZONE:America/New_York
PRODID:-//Apple Inc.//iCal 3.0//EN
CALSCALE:GREGORIAN
X-WR-CALNAME:test
VERSION:2.0
X-WR-RELCALID:1884C7F8-BC8E-457F-94AC-297871967D5E
X-APPLE-CALENDAR-COLOR:#2CA10B
BEGIN:VTIMEZONE
TZID:US/Eastern
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
DTSTART:20070311T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
TZNAME:EDT
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
DTSTART:20071104T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
TZNAME:EST
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
SEQUENCE:5
TRANSP:OPAQUE
UID:00481E53-9258-4EA7-9F8D-947D3041A3F2
DTSTART;TZID=US/Eastern:20090224T090000
DTSTAMP:20090225T000908Z
SUMMARY:Test Event
CREATED:20090225T000839Z
DTEND;TZID=US/Eastern:20090224T100000
RRULE:FREQ=DAILY;INTERVAL=1;UNTIL=20090228T045959Z
END:VEVENT
END:VCALENDAR
ENDCAL

**Beware of the initial whitespace in the above example which is for rdoc formatting.** The parser does not strip initial whitespace from lines in the file and will fail.

As already stated the string argument may be a full icalendar format calendar, or just one or more subcomponents, e.g.

RiCal.parse_string("BEGIN:VEVENT\nDTSTART;TZID=US/Eastern:20090224T090000\nSUMMARY:Test Event\nDTEND;TZID=US/Eastern:20090224T100000\nRRULE:FREQ=DAILY;INTERVAL=1;UNTIL=20090228T045959Z\nEND:VEVENT")

File.open("path/to/file", "r") do |file|
  components = RiCal.parse(file)
end

Event, Journal, and Todo components can have recurrences which are defined following the RFC 2445 specification. A component with recurrences can enumerate those occurrences.

These components have common methods for enumeration which are defined in the RiCal::OccurrenceEnumerator module.

To get an array of occurrences, Use the RiCal::OccurrenceEnumerator#occurrences method:

event.occurrences

This method may fail with an argument error, if the component has an unbounded recurrence definition. This happens when one or more of its RRULES don't have a COUNT, or UNTIL part. This may be tested by using the RiCal::OccurrenceEnumerator#bounded? method.

In the case of unbounded components, you must either use the :count, or :before options of the RiCal::OccurrenceEnumerator#occurrences method:

event.occurrences(:count => 10)

or

event.occurrences(:before => Date.today >> 1)

Another option on the occurrences method is the :overlapping option, which takes an array of two Dates, Times or DateTimes which are expected to be in chronological order. Only events which occur either partially or fully within the range given by the :overlapping option will be enumerated.

Alternately, you can use the RiCal::OccurrenceEnumerator#each method, or another Enumerable method (RiCal::OccurrenceEnumerator includes Enumerable), and terminate when you wish by breaking out of the block.

event.each do |event|
  break if some_termination_condition
  #....
end

Starting with version 0.8.0 RiCal will parse calendars and components which contain nonstandard components.

For example, there was a short-lived proposal to extend RFC2445 with a new VVENUE component which would hold structured information about the location of an event. This proposal was never accepted and was withdrawn, but there is icalendar data in the wild which contains VVENUE components.

Prior to version 0.8.0, RiCal would raise an exception if unknown component types were encountered. Starting with version 0.8.0 RiCal will 'parse' such components and create instances of NonStandard component to represent them. Since the actual format of unknown components is not known by RiCal, the NonStandard component will simply save the data lines between the BEGIN:xxx and END:xxx lines, (where xxx is the non-standard component name, e.g. VVENUE). If the calendar is re-exported the original lines will be replayed.

RFC2445 allows 'non-standard' or experimental properties which property-names beginning with X. RiCal always supported parsing these.

The standard properties are specified as to how many times they can occur within a particular component. For singly occurring properties RiCal returns a single property object, while for properties which can occur multiple times RiCal returns an array of property objects.

While implementing NonStandard properties, I realized that X-properties were being assumed to be singly occurring. But this isn't necessarily true. So starting with 0.8.0 the X-properties are represented by an array of property objects.

THIS MAY BREAK SOME APPLICATIONS, but the adaptation should be easy.

• RiCal requires that an implementation of TZInfo::Timezone. This requirement may be satisfied by either the TzInfo gem, or by a recent(>= 2.2) version of the ActiveSupport gem which is part of Ruby on Rails.

sudo gem install ri_cal

sudo gem install rubyredrick-ri_cal --source http://gems.github.com/

1. cd to a directory in which you want to install ri_cal as a subdirectory
2. git clone http://github.com/rubyredrick/ri_cal your_install_subdirectory
3. cd your_install_directory
4. rake spec
5. rake install_gem

(The MIT License)

Copyright (c) 2009 Richard J. DeNatale

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the 'Software'), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.