The problem it solves
The business’s dates are spread across personal calendars and a sheet on the wall, so nobody sees a whole week at once and the monthly meeting is missed in a short month. What is needed is one calendar for the business, read by month, week and day, with repeats counted from the start date rather than from the last time.
Who it is for
- All teams
- Whoever keeps the business’s diary
Available today
Month, week and day on one screen
Three zooms on the same question with a switch between them, rather than three links that make a reader choose before they have seen anything.
An all-day event is a date, not an instant
A timed event is two instants in UTC, so a nine o’clock Riyadh meeting reads as six to a colleague in London. An all-day event is two dates with no clock at all, so “the 20th” is the 20th in Riyadh, London and Los Angeles. The database refuses a row that is neither shape.
Repeats counted from the start date
Daily, weekly, monthly and yearly, with an interval and an end by date or by count. A monthly event starting on 31 January falls on 28 February and then comes back to 31 March, because every occurrence is counted from the start and not from the one before it — otherwise February would drag it to the 28th for ever.
A rule and its exceptions, not a row for every occurrence
A repeating event is one row. Skip an occurrence, move one to another day even in another month, or put it back under the rule — the rest are untouched, and moving the same one twice corrects its exception rather than growing a second.
Who is invited and what they said
Invite colleagues from the organisation’s team and they accept or decline; correcting the place or the time wipes no answer already given and takes nobody off the list. Somebody who was not invited cannot answer for the room.
It reads the other apps and copies nothing
Bookings, approved leave and hire returns appear in the window on screen by reading their own tables at that moment. Cancel a booking and it is gone from the calendar on the next render, because the calendar never had a copy of it to forget to delete.
Works with
On one set of data: what happens here reaches these apps without anyone retyping it.
Frequently asked questions
Is this the same as the Appointments app?
No. Appointments sells a slot to a customer: a service with a duration, a price and a provider, with free times computed and clashes refused, because the slot is scarce and somebody is paying for it. The calendar is the business’s own time: two events may overlap, because a delivery window and a morning stand-up genuinely do, and there is no price and no reference number. What the calendar has and Appointments does not is recurrence.
What does a monthly event starting on the 31st do?
It lands on the last day of a short month and then comes back. A monthly event starting on 31 January falls on 28 February and then on 31 March, because every occurrence is counted from the start date and not from the one before it — otherwise February would drag it to the 28th for ever.
Does it tell an all-day event from a timed one?
Yes, and in the schema rather than on the screen. A timed event is two instants in UTC, so a nine o’clock Riyadh meeting reads as six to a colleague in London. An all-day event is two dates with no clock at all, so “the 20th” is the 20th in Riyadh, London and Los Angeles. The database refuses a row that is neither shape.
Do bookings and leave show on the calendar?
Yes — read, not copied. Bookings, approved leave and hire returns are read from their own tables at render time, so cancelling a booking removes it from the calendar on the next render — because the calendar never had a copy of it to forget to delete.