Development design choices

  • Timezone support. Every event has a timezone.

  • Usage of pytz. The timezone library used it pytz. Other timezone identifiers than defined in pytz (Olson database) are not supported.

  • Dropped support for ambiguous timezones. Three letter timezones like CET, MET, PST, etc. are not supported.

  • Start/end datetime inputs are treated as localized values. If a timezone on an event is changed afterwards, the datetime values are not converted to the target timezone.

  • Whole day events last from 0:00 until 23:59:59 on the same day.

  • Open end events end on the same day at 23:59:59.

  • For recurring events, we do not support unlimited occurrences. The number of possible recurrences of an event is limited to 1000 occurrences. This way, indexing and other operations doesn’t take too long. The maximum number of occurrences is set via the MAXCOUNT constant in plone.event.recurrence.

  • We save the timezone of the event now (since 2.0) on start and end in datetime as tzinfo expecting implicitly a valid pytz. That way we ensure to not loose the original timezone. It does not matter if its stored in UTC or not, because a timezone is just that: a timezone. UTC is also just a timezone. Not converting here to UTC makes thing less complex and gives maximum flexibility. Calculation can be done easily from one timezone to an other timezone if needed at display time. Also we now may have different timezones on start and end. Even if this a rare use-case now we can support movement between timezone, i.e a flight or train ride. Not supported are naive datetimes, since we can not calculate anything with them nor does DateRecurringIndex or dateutil.rrule supports them. Thus the use-case of a world plone day happens on a date all over the world the whole day in every timezone is not supported. This is not a limitation of not supporting naive datetimes, moreover we need a special timezone i.e wholeworld and an index and calculation methods that can deal with it. This makes things way more complex and so we decided to skip that feature for now.

  • We identified two major use-cases: 1) The event happens at a physical location, i.e. a project meeting happens in Madrid with participant traveling to Madrid weekly on monday at 9:00am. 2) A phone conference of an international organisation with participants from all over the world happens every work day at 10:00 am.

    In both cases we create the event with the date with a given timezone. So for use-case (1) the editor sits in Taipeh but edits a conference in Madrid, so she has to set the timezone of the event in the form. At display time usally the viewer is interested to see the local time of the conference in the output, so display should be in Europe/Madrid timezone.

    In use-case (2) the editor usally refers to his own local timezone. He will keep the preset in the form. At display time the viewer is interested to see the date and time in his local timezone. On change of daylight-saving time in the original timezone the datetime was entered stays on 10:00am. But if the participant in a other timezone has not this change it means he has the call scheduled one hour earlier or later in summer or winter time. So DST makes things again difficult, but heres no way to get rid of it as long as theres the concept of daylightsaving time is handled differently all over the world.