Announcing ri_cal version 0.8.8 a new implementation of RFC2445 in Ruby
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
Changes:
=== v0.8.8 2011-02-13 Regenerate gemspec for version 0.8.8 Version bump to 0.8.8 fix x property access change rakefile to use ad_agency === v0.8.7 2010-04-16 Regenerated gemspec for version 0.8.7 update history Version bump to 0.8.7 fix tickets #29-supress x-rical-tzsource when not relevant === v0.8.6 2010-04-15 Regenerated gemspec for version 0.8.6 update history prior to release Version bump to 0.8.6 fix tzinfo timezone export force change managment datetimes to zulu time added ZuluDateTime property for use by change management properties parked a spec Convert to jeweler Version bump to 0.8.5 remove unneeeded Date#to_time and DateTime#to_time methods remove inf loop spec temporarily Working on a bug where a recurrence rule with simple by-parts caused an infinite loop See spec/ri_cal/inf_loop_spec
Although the reported bug is fixed there is still work to do because giving an event a dtstart not within the recurrence rule produces incorrect output.
1) 'an event with unneeded by parts with a dtstart outside the recurrence rule should enumerate 10 events first July 12, 1940, July 13, 1940, July 13, 1941 when count is 3' FAILED expected: ["1940-07-12", "1940-07-13", "1941-07-13"], got: ["1940-07-12", "1940-07-13", "1941-07-12"] (using ==)
I'm going to push this to github, but not release a new gem version until I can fix this latter bug.
fixed infinite loop bug for reported case website and gemspec Fixed Ticket #26, failing with date values for event dtstart and dtend updated website === v0.8.4 2009-09-18 fixed gemspec problem === v0.8.3 2009-09-18 prepared to publish refactored occurrence incrementers checkpoint changed ri_cal.rb to autoload changed ri_cal.rb to autoload === v0.8.2 2009-09-05 another attempt to trigger github to rebuild fixed gem version so github should now build Fixes http://rick_denatale.lighthouseapp.com/projects/30941/tickets/23 initialization_methodsrb-syntax Fixes http://rick_denatale.lighthouseapp.com/projects/30941/tickets/24 need-to-handle-empty-property-values fixed ticket #23 adopted patch from ebigart Support properties with no value (e.g. 'LOCATION;LANGUAGE=en-US:' gets generated using Outlook) === v0.8.1 2009-08-18 Fixes http://rick_denatale.lighthouseapp.com/projects/30941/tickets/21 exception-when-count-option-used-to-enumerate-non-recurring-event === v0.8.0 2009-08-11 Minor Version Bump - There is a small potentially breaking change see section on treatment of X-properties below * Unknown Components
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.
* Change to treatment of X-properties
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.
- No changes other than a version number bump. github seems to have failed to notice the commit of v0.7.6 and didn't build the gem. Hopefully it will notice this one.
