-
Notifications
You must be signed in to change notification settings - Fork 3
Add basic support for parsing VALARM #2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
I should also note that alarm triggers can be a duration or a datetime. As a result, the PR uses |
jonathanballs
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for using Magical and thank you for this PR!
This looks great and I can see that you've been through the codebase and actually kept things quite consistent with the design that I initially created. I have a small comment about your use of Duration but otherwise all is fine. As for your question as to whether we should support Duration given that it's a newer addition to the Elixir stdlib my opinion is that it's fine - and indeed within the spirit of this library to parse these durations into native elixir types!
| alias Magical.Parser.DateParser | ||
|
|
||
| def parse("P" <> _rest = duration_string, _args) do | ||
| Duration.from_iso8601!(duration_string) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The convention that I created within the DateParser was that if a field was not parseable that it should be left as nil
| Duration.from_iso8601!(duration_string) | |
| Duration.from_iso8601(duration_string) | |
| |> case do | |
| {:ok, duration} -> duration | |
| error -> nil | |
| end |
|
Also I know that I've been slow to respond to this PR but I will be much more on top of it now! I did actually start work on this feature last year when an issue was raised (on which you commented) however I did not get round to finishing it. I'm happy to lend a hand if need be otherwise I'll let you get onto it! Thanks again :) |
|
I have updated the github workflow to run tests on PRs and new branches so if you rebase onto |
|
Hey folks! I'm testing this branch on an ics export of my google calendar, and I'm getting a failure which may be interesting to you. It dies on This looks legit according to the RFC, since a VALARM can contain some email-related fields when the |
|
Good callout - I'll update my PR and resubmit. I'll also recheck against the RFC (I so far only focused on calendar exports too). |
|
I went ahead and fixed it in a branch, then I found out that |
This very presumptuous PR adds basic support for parsing VALARM entries in events. It is currently missing:
I'd rather get feedback early than go down a wrong path too far, hence this initial PR. I've tested it on a fairly large
.icsfile (my personal calendar) and everything appears to parse correctly but I haven't added tests yet.