This fixes collective#165

see collective#152

Check that event is included in parsing

…components as equal to the bigger component

Add documentation about parsing

updated about.rst to include details that the repo is not obsolete and  still compliant with RFC5545

Exposed by running in `python3 -b` mode.

Fix `vText.__repr__` `BytesWarning`

version 5.0.8

See https://icalendar.readthedocs.io/en/latest/maintenance.html#new-releases

The time zone was missing from PERIOD values.
See niccokunzmann/python-recurring-ical-events#113

Add timezone to period value types

version 5.0.9

See https://icalendar.readthedocs.io/en/latest/maintenance.html#new-releases

- did not reference self at all
- keeps compatibility with existing code
- makes testing easier

Signed-off-by: Felix Stupp <felix.stupp@banananet.work>

Signed-off-by: Felix Stupp <felix.stupp@banananet.work>

Signed-off-by: Felix Stupp <felix.stupp@banananet.work>

Signed-off-by: Felix Stupp <felix.stupp@banananet.work>

Component._encode: merge instead of ignore parameters on natives

version 5.0.10

Previously the start and end datetimes were always printed out in the
timezone that they appear in the calendar entry.

In 7a8d584 duration support was added and an attempt was already made
to display the datetime in the local timezone. Unfortunately in that
specific case the `start.astimezone(start.tzinfo)` is a no-op and does
absolutely nothing. Unlike the name suggests, `astimezone()` adjusts the
date and time data, such that they match the passed tzinfo, but since
that is the same timezone data as before, nothing changes. [0]

In order to properly convert to the user's local timezone, we need to
call the method with no arguments.

With this the timezone is always properly displayed, which makes up for
a much nicer UX for users of the cli.

The test has to be adapted to expect the datetime in the local timezone,
hence we cannot hardcode the entire expected string anymore.

[0] https://docs.python.org/3/library/datetime.html#datetime.datetime.astimezone