> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ruber.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Calendar

> Events, repeating rules that survive daylight saving, editing one occurrence, a second time zone, and booking links.

## Views

Six: **Day**, **3 days**, **Week**, **Month**, **Year** and **Agenda**. Three
days exists because it is the range that fits a laptop screen without the week's
columns getting too narrow to read.

Which one opens by default, whether the clock is 12 or 24 hour, how long a new
event is, and how far ahead a reminder fires are all settings. They follow your
account, so a device you sign in on later matches.

## Repeating events

A repeating rule is expanded in **wall-clock time** and mapped to your zone
afterwards. That ordering is what RFC 5545 defines, and it is the reason "every
weekday at 09:00" is still nine o'clock on the morning the clocks change rather
than eight or ten for half the year.

If you have been bitten by a calendar that drifts an hour twice a year, this is
the part that was got right.

### Changing one occurrence

Move or cancel a single occurrence and the series carries on. The change is
stored as an exception to the rule, not as a copy that has stopped following it
— so editing the series later still updates every occurrence you did not touch.

You are asked whether a change applies to one occurrence or the whole series.
The answer is not guessed from what you dragged.

## Two time zones

Show a second zone beside your own. If you work with people several hours away,
the useful question is what time it is for them, and answering it should not
need arithmetic in your head.

## Booking links

Publish a link and let someone take a slot. Each link carries:

* **duration** — how long the meeting is
* **buffer** — gap either side, so meetings do not touch
* **lead time** — how much notice you need
* **horizon** — how far ahead people may book
* **days** and **hours** — the window you are bookable in
* **time zone** — the one the window is expressed in

Availability is computed from the calendar the link points at, so a slot already
taken is never offered. **The person booking sees free time and never what is in
it** — they get availability, not your diary.

Booking needs no account. The guest gives a name, an address and an optional
note. The event lands on your calendar and they get the details.

## Private calendars

A calendar under a Private mailbox is sealed in your browser before it is saved.
The server stores what it is handed and holds no key, so an event title never
exists in the clear on our side.

This follows the mailbox rather than being a switch of its own, and it has a
real cost worth understanding: a calendar the server cannot read is one it
cannot search, cannot expand for a reminder, and cannot offer to a booking link.
Privacy of that strength buys out the features that need a server to look.

## What the calendar does not do

**No invitations.** There are no attendees on an event, no accept or decline,
and no checking whether somebody else is free. Booking links are the only route
from another person to your calendar, and they work the other way round — they
pick from your time rather than negotiating over it.

**No sync.** No CalDAV, no subscribed feeds, no `.ics` import or export. A
calendar you keep elsewhere stays there.

**Reminders depend on a job runner.** They are written and scheduled; whether
they are delivered depends on the background runner being connected on your
deployment. If reminders matter to you, confirm they are arriving before relying
on them.