Smaller PRs are always easier to review and can help prevent spending too much time/effort working down a “wrong” direction. I’m a big fan of stacked PRs for this reason 
I’m also happy to review bigger PRs if needed, though. Whichever is more comfortable for you.
Please feel free to contribute PRs removing specific Timex calls. This really does not (should not!) be done all at once. One task, for instance, might be to remove use of Timex.to_date Timex.to_datetime in tests. This would leave other uses of Timex in tests, but it would get rid of one class of them. Doing this one-bite at a time is both faster per-PR and a bit safer as we can more easily test each set of changes in isolation.
I created this issue to help track that work: Remove Timex dependency · Issue #32 · expothecary/ical · GitHub
The way this is restructured is really nice to work with! (especially after doing stuff with the original lib).
This is a major release which drops support for Elixir versions older than 1.17, but also drops the dependency on Timex which will make it easier to use in a greater variety of applications.
Aside from a handful of bugfixes to the prior release (v1.1.2) and documentation improvements, the headline improvement is full recurrence support. This also unlocked the ability to properly determine when the next alarms should be triggered for the user.
The recurrence implementation implements the full RFC5545 recurrence rule specification. To my knowledge, this is the first such implementation done without external dependencies and in pure Elixir.
Its test suite includes every recurrence rule example in the RFC, and (of course) passes them.
Performance is acceptable: most recurrences are fully calculated in 50-200 microseconds on a Core i7-9700F @ 3Ghz (a seven year-old processor at this point), though some of the examples from the RFC take up 3ms on the same system.
A massive thank-you to all the contributors of code and PR review, including @W3NDO, @mpl,and Max Salminen, as well as those who reported issues.
We also welcomed @mpl as a new collaborator to the git repository, as they helped move things forward towards this significant release.
This sounds amazing. Can’t wait to try it. Thanks for the hard work.
I know this comment is a bit pointless, but I’ve been struggling with bad ical-parsing (esp. recurrence) in an existing non-elixir application, and not been sure about which direction to move in. I saw your thread here some time ago, and just randomly tried finding it again today to see if there had been progress on recurrence. What luck.
Thanks.
Sometimes it really is all about timing 
(excuse the horrible pun)
If you do find any issues whatsoever with the recurrence, please drop an issue on the repo and I’ll get it taken care of. Happy hacking!
I finally started looking at the library, so far so good.
I’m so fortunate to have to deal with ics-files generated by outlook 365, where all day events have dtstart/dtend set as just a date, and with no timezone information in the ics file. How do I define/override the timezone of all day events? Ical parses them as a Date (not DateTime), so I guess I could just pattern match on it and handle it on the fly, but it would be neat to be able to force the Date’s into DateTime’s with a supplied time zone.
(or maybe there’s a better way of doing it - I’m basically just trying to parse ics files and get a list of events with start/end dates in the correct timezone, no matter if its normal events of all day events)
Thanks