Calendar
Time that behaves when the clocks change.
A calendar that gets the hard parts right: repeating events that hold up when the clocks change, one occurrence moved without breaking the series, and a second time zone beside your own. Booking links let someone take your free time without seeing what is in it. It does not do invitations, and the last section says so.
- Views
- Day
- 3 days
- Week
- Month
- Year
- Agenda
- Every booking link controls
- duration
- buffer
- lead time
- horizon
- days
- hours
- time zone
The hard part of a calendar is the last Sunday in October.
A repeating rule is expanded in wall-clock time and mapped to the zone afterwards — the order RFC 5545 defines, and the reason “every weekday at 09:00” is still nine o'clock the Monday after the clocks go back. Expand the same rule in UTC instead, which is the easier thing to write, and the hour slides by one the moment the offset changes and stays slid until spring.
Time, done properly
- 01
Recurrence that survives daylight saving
A repeating rule is expanded in wall-clock time and mapped to the zone afterwards, the order RFC 5545 defines. It is why “every weekday at 09:00” is still nine o'clock the morning the clocks change, rather than eight or ten for half the year.
- 02
Change one occurrence, keep the series
Move one occurrence, or cancel one, without detaching it from the series. The rest of the rule carries on, and the exception is stored as an exception rather than as a copy that stops following the rule.
- 03
A second zone, alongside
Show a second time zone beside your own. If you work with people five hours away, the useful question is what time it is for them, and answering it should not require arithmetic.
Seeing it
- 04
Six views, including one for a small screen
Day, three days, week, month, year and agenda. Three days is there because it is the range that fits a laptop screen without the week's columns becoming too narrow to read.
- 05
Set up the way you read time
Twelve or twenty-four hour clock, the default length of a new event, which view opens first, and how far ahead a reminder fires. Set once, and every device you sign in on follows.
- 06
Tasks and time in one place
A task can point at a calendar event, so the thing to do and the time set aside to do it stay one item rather than two that drift apart.
Booking links
- 07
Seven controls, not a toggle
Publish a link with a duration, a buffer between meetings, how much notice you need, how far ahead people may book, which days and which hours. Someone picks a slot; the event appears.
- 08
Your calendar decides, and reveals nothing
Availability is computed from the calendar the link points at, so a slot that is taken is not offered. The person booking sees free time, never what is in it.
- 09
No account for the person booking
A booking page needs no account. The guest gives a name, an address and an optional note, and that is the whole transaction.
Private calendars
- 10
Sealed before it leaves the browser
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.
- 11
It follows the mailbox, not a setting
Encryption follows the mailbox rather than being a switch of its own. A Smart calendar is meant to be readable and is; a Private one is not, and the code refuses to save plaintext for it rather than falling back.
What it does not do
Every page like this one lists what a product is good at, which is why that list tells you nothing. These are the limits, named before you find them.
- 01
No invitations, and no attendees
You cannot invite anyone to an event. There are no attendees, no accept or decline, and no checking whether somebody else is free. Booking links are the only path from another person to your calendar, and they run the other way round — they pick from your time rather than negotiating over it.
- 02
It does not sync with anything
No CalDAV, no subscribed feeds, no import from an .ics file, and no export to one. A calendar you keep elsewhere stays elsewhere. This is the honest blocker and it is the first thing worth knowing.
- 03
Reminders depend on a job runner
Reminders exist in the code and run on a scheduled job runner. Whether that runner is connected is a deployment question, and on a deployment where it is not, a reminder is written and never delivered. Better said here than discovered on the day.
- 04
Sealed calendars give up server-side features
Because a Private calendar is sealed in the browser, the server cannot read it — which also means it cannot search it, cannot expand its rules for a reminder, and cannot offer its free time to a booking link. Privacy of that strength costs the features that need a server to look.
It is included with every mailbox — there is nothing else to turn on.
Open Calendar