JSCalendar — the JSON representation of calendar data (RFC 8984).

JSCalendar says what iCalendar says — events, tasks, recurrence, participants, time zones — in a form that does not need its own parser. It is the IETF's intended successor to iCalendar, and where iCalendar's line-folding, escaping and property parameters have produced two decades of interoperability bugs, this is a JSON object with named fields.

This library reads and writes that format. It does not schedule, and it does not expand recurrences; it turns documents into structs and back, faithfully.

iex> {:ok, event} = JSCalendar.decode(~s({
...>   "@type": "Event",
...>   "uid": "review-2026-06",
...>   "updated": "2026-06-01T09:00:00Z",
...>   "title": "Quarterly review",
...>   "start": "2026-06-02T09:00:00",
...>   "duration": "PT1H"
...> }))
iex> {event.title, event.start}
{"Quarterly review", ~N[2026-06-02 09:00:00]}

Three things it takes seriously

Unknown properties survive. Vendor extensions and later revisions of the specification both arrive as properties this library has never heard of. They are kept in each object's extra map and written back untouched, because a reader that silently drops what it does not understand corrupts data it was only asked to relay.

Defaults are not written back. A property equal to its RFC default is omitted on encode — its absence already says the same thing — so a document does not grow every time it is read and rewritten.

No dependencies. Erlang's :json and Elixir's Duration are both standard library, so nothing is pulled in to parse a document or read a duration.

What is not here yet

recurrenceOverrides, localizations and custom timeZones are preserved verbatim rather than parsed into structures — they are PatchObjects and time zone definitions whose semantics deserve their own attention rather than a hurried first pass. They round-trip correctly; they are simply not yet typed.