Next major rewrite scratchpad / tasks

[simshaun]

LATE EDIT: Just found https://github.com/fruux/sabre-vobject. Is a major overhaul even worth doing?

From #94:

• Build an iCalendar object parser specifically to extract VEVENTs.
• Build a RecurrenceGenerator that handles an extracted VEVENT. Use generators instead of generating a giant collection all at once. No more virtualLimit. (From Add a getNextRecurrence method #91)
  • Instead of being large like v1 ArrayTransformer, refactor into smaller units.
• To ease the pain of upgrading, create a VEVENT builder class that accepts a RRULE string and supports building by method chaining, v1-style.

From #84:

• Hint \DateTimeInterface instead of concrete implementations.
• Use \DateTimeImmutable to reduce chance of unintended by-reference object modifications.

Because of #106:
https://tools.ietf.org/html/rfc5545#section-3.3.5

• DTSTART and other attributes that hold DATE-TIME values need to support TZID references.
• DATE-TIME values without a TZID or UTC designator must be recognized as floating times.
  • Figure out the best way to handle this.
    • Wrap \DateTime objects in a class that has isFloatingTime(). It would be up to users to handle floating times in their applications.
    • Store as UTC so users can easily convert to visitors' timezone if needed.

From #87:

• Support RFC7529 SKIP property to handle non-gregorian dates. No more lastDayOfMonthFix.

From #88:

• Support period values in RDATE (as well as DATE & DATE-TIME). Are there other attributes that need period value support?

From #89:

• When RDATE is simply a DATE value, in the resulting Recurrence object (or \DateTime wrapper from Issue with rule when DTSTART is set and "Z" Time Zone Identifier is apart of the datetime string. #106 checklist, see above), indicate that no time was explicitly defined.

From #91:

• Store context (such as occurrence #, limit, end date, ..) in generated recurrences? Make it possible generate occurrences at a later time given any single recurrence.
• Brainstorm ideas to accomplish "get next recurrence from the present moment". Probably not feasible beyond generating from the start and tossing out those that aren't needed.

From #93:

• Figure out if there's a more efficient way to calculate recurrences than "looping through each day and testing".
• Adding to the previous item, try to avoid generating so many \DateTime objects.