icalendar 3.2

iCalendar parser/generator

The icalendar package is a parser/generator of iCalendar files for use with Python.

---

Homepage:

http://icalendar.readthedocs.org

Code:

http://github.com/collective/icalendar

Mailing list:

http://github.com/collective/icalendar/issues

Dependencies:

setuptools and since version 3.0 we depend on pytz.

Tested with:

Python 2.4 - 2.7

License:

BSD

---

Changes in version 3.0

API Change

Since version we unified to icalendar de/serialization API to use only to_ical (for writing an ical string from the internal representation) and from_ical (for parsing an ical string into the internal representation).

to_ical is now used instead of the methods ical, string, as_string and instead of string casting via __str__ and str.

from_ical is now used instead of from_string.

This change is a requirement for future Python 3 compatibility. Please update your code to reflect to the new API.

Timezone support

Timezones are now fully supported in icalendar for serialization and deserialization. We use the pytz library for timezone components of datetime instances. The timezone identifiers must be valid pytz respectively Olson database timezone identifiers. This can be a problem for ‘GMT’ identifiers, which are not defined in the Olson database.

Instead of the own UTC tzinfo implementation we use pytz UTC tzinfo object now.

About this fork which is not a fork anymore

Aim of this fork (not fork anymore, read further) was to bring this package up to date with latest icalendar RFC specification as part of plone.app.event project which goal is to bring recurrent evens to Plone.

After some thoughts we (Plone developers involved with plone.app.event) send a suggestion to [e-mail] to take over mainaining of icalendar. Nobody object and since version 2.2 we are back to development.

Test Coverage Report

Output from coverage test:

lines   cov%   module   (path)
   13   100%   icalendar.__init__
  227    91%   icalendar.cal
   48    91%   icalendar.caselessdict
  166    92%   icalendar.parser
  667    90%   icalendar.prop
   16   100%   icalendar.tests.test_cases
   25    96%   icalendar.tests.test_doctests
   47   100%   icalendar.tests.test_encoding
   44    34%   icalendar.tests.test_icalendar
   13   100%   icalendar.tests.test_property_params
   51   100%   icalendar.tests.test_timezoned
   53    30%   icalendar.tools

Changelog

3.2 (2012-11-27)

• Documentation file layout restructuring. [thet]

• Fix time support. vTime events can be instantiated with a datetime.time object, and do not inherit from datetime.time itself. [rdunklau]

• Correctly handle tzinfo objects parsed with dateutil. Fixes #77. [warvariuc, thet]

• Text values are escaped correclty. Fixes #74. [warvariuc]

• Returned old folding algorithm, as the current implementation fails in some cases. Fixes #72, Fixes #73. [warvariuc]

• Supports to_ical() on date/time properties for dates prior to 1900. [cdevienne]

3.1 (2012-09-05)

• Make sure parameters to certain properties propagate to the ical output. [kanarip]

• Re-include doctests. [rnix]

• endure correct datatype at instance creation time in prop.vCalAddress and prop.vText. [rnix]

• Apply TZID parameter to datetimes parsed from RECURRENCE-ID [dbstovall]

• Localize datetimes for timezones to avoid DST transition errors. [dbstovall]

• Allow UTC-OFFSET property value data types in seconds, which follows RFC5545 specification. [nikolaeff]

• Remove utctz and normalized_timezone methods to simplify the codebase. The methods were too tiny to be useful and just used at one place. [thet]

• When using Component.add() to add icalendar properties, force a value conversion to UTC for CREATED, DTSTART and LAST-MODIFIED. The RFC expects UTC for those properties. [thet]

• Removed last occurrences of old API (from_string). [Rembane]

• Add ‘recursive’ argument to property_items() to switch recursive listing. For example when parsing a text/calendar text including multiple components (e.g. a VCALENDAR with 5 VEVENTs), the previous situation required us to look over all properties in VEVENTs even if we just want the properties under the VCALENDAR component (VERSION, PRODID, CALSCALE, METHOD). [dmikurube]

• All unit tests fixed. [mikaelfrykholm]

3.0.1b2 (2012-03-01)

• For all TZID parameters in DATE-TIME properties, use timezone identifiers (e.g. Europe/Vienna) instead of timezone names (e.g. CET), as required by RFC5545. Timezone names are used together with timezone identifiers in the Timezone components. [thet]

• Timezone parsing, issues and test fixes. [mikaelfrykholm, garbas, tgecho]

• Since we use pytz for timezones, also use UTC tzinfo object from the pytz library instead of own implementation. [thet]

3.0.1b1 (2012-02-24)

• Update Release information. [thet]

3.0

• Add API for proper Timezone support. Allow creating ical DATE-TIME strings with timezone information from Python datetimes with pytz based timezone information and vice versa. [thet]

• Unify API to only use to_ical and from_ical and remove string casting as a requirement for Python 3 compatibility: New: to_ical. Old: ical, string, as_string and string casting via __str__ and str. New: from_ical. Old: from_string. [thet]

2.2 (2011-08-24)

• migration to https://github.com/collective/icalendar using svn2git preserving tags, branches and authors. [garbas]

• using tox for testing on python 2.4, 2.5, 2.6, 2.6. [garbas]

• fixed tests so they pass also under python 2.7. [garbas]

• running tests on https://jenkins.plone.org/job/icalendar (only 2.6 for now) with some other metrics (pylint, clonedigger, coverage). [garbas]

• review and merge changes from https://github.com/cozi/icalendar fork. [garbas]

• created sphinx documentation and started documenting development and goals. [garbas]

• hook out github repository to http://readthedocs.org service so sphinx documentation is generated on each commit (for master). Documentation can be visible on: http://readthedocs.org/docs/icalendar/en/latest/ [garbas]

2.1 (2009-12-14)

• Fix deprecation warnings about object.__init__ taking no parameters.

• Set the VALUE parameter correctly for date values.

• Long binary data would be base64 encoded with newlines, which made the iCalendar files incorrect. (This still needs testing).

• Correctly handle content lines which include newlines.

2.0.1 (2008-07-11)

• Made the tests run under Python 2.5+

• Renamed the UTC class to Utc, so it would not clash with the UTC object, since that rendered the UTC object unpicklable.

2.0 (2008-07-11)

• EXDATE and RDATE now returns a vDDDLists object, which contains a list of vDDDTypes objects. This is do that EXDATE and RDATE can contain lists of dates, as per RFC.

  *Note!*: This change is incompatible with earlier behavior, so if you handle EXDATE and RDATE you will need to update your code.

• When createing a vDuration of -5 hours (which in itself is nonsensical), the ical output of that was -P1DT19H, which is correct, but ugly. Now it’s ‘-PT5H’, which is prettier.

1.2 (2006-11-25)

• Fixed a string index out of range error in the new folding code.

1.1 (2006-11-23)

• Fixed a bug in caselessdicts popitem. (thanks to Michael Smith <[e-mail]>)

• The RFC 2445 was a bit unclear on how to handle line folding when it happened to be in the middle of a UTF-8 character. This has been clarified in the following discussion: http://lists.osafoundation.org/pipermail/ietf-calsify/2006-August/001126.html And this is now implemented in iCalendar. It will not fold in the middle of a UTF-8 character, but may fold in the middle of a UTF-8 composing character sequence.

1.0 (2006-08-03)

• make get_inline and set_inline support non ascii codes.

• Added support for creating a python egg distribution.

0.11 (2005-11-08)

• Changed component .from_string to use types_factory instead of hardcoding entries to ‘inline’

• Changed UTC tzinfo to a singleton so the same one is used everywhere

• Made the parser more strict by using regular expressions for key name, param name and quoted/unquoted safe char as per the RFC

• Added some tests from the schooltool icalendar parser for better coverage

• Be more forgiving on the regex for folding lines

• Allow for multiple top-level components on .from_string

• Fix vWeekdays, wasn’t accepting relative param (eg: -3SA vs -SA)

• vDDDTypes didn’t accept negative period (eg: -P30M)

• ‘N’ is also acceptable as newline on content lines, per RFC

0.10 (2005-04-28)

• moved code to codespeak.net subversion.

• reorganized package structure so that source code is under ‘src’ directory. Non-package files remain in distribution root.

• redid doc/.py files as doc/.txt, using more modern doctest. Before they were .py files with big docstrings.

• added test.py testrunner, and tests/test_icalendar.py that picks up all doctests in source code and doc directory, and runs them, when typing:

  python2.3 test.py

• renamed iCalendar to lower case package name, lowercased, de-pluralized and shorted module names, which are mostly implementation detail.

• changed tests so they generate .ics files in a temp directory, not in the structure itself.

License

Copyright (c) 2012, Plone Foundation All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

• Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

• Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.