Time zones, all-day events and recurrence
Model instants, local dates and recurring events without silent assumptions.
Reviewed · 2026-09-20 / Ridian
An instant needs an offset
Section titled “An instant needs an offset”Use an explicit UTC Z or numeric offset in API timestamps: 2026-10-25T10:00:00+01:00. An IANA zone such as Europe/Berlin describes civil-time rules; it does not replace the timestamp’s offset. Avoid ambiguous names such as “CST”.
All-day is a local date
Section titled “All-day is a local date”An all-day event is not always 24 elapsed hours. In Europe/Berlin, 25 October 2026 spans 25 hours because daylight saving time ends. Preserve the local date and use the intended calendar zone when comparing occupied intervals.
CalDAV live queries accept timeZone in MCP or time_zone in REST. If the calendar does not provide a usable zone, Ridian requires an explicit IANA zone instead of silently assuming UTC. Ask the user when the zone is unknown.
A series is not a pile of independent events
Section titled “A series is not a pile of independent events”A recurring series has rules and may contain moved or cancelled occurrences. Reading a range must account for those exceptions. Creating many separate weekly events does not create a native recurring series.
Ridian’s MCP supports a bounded weekly-series creation path for Google and Microsoft. Read the exact create_event schema and supported recurrence fields in the tool reference. CalDAV can read existing series but does not support their creation, modification or deletion through this adapter.
Use bounded windows
Section titled “Use bounded windows”Event and availability queries are limited to 20 calendars and 31 days. Ask for the hours you need; a whole-week query includes nights unless you constrain it. For a dense calendar, use smaller windows rather than assuming a partial result is complete.