---
title: Inner and variant events
description: Two ideas other calendars don't have: events that only happen inside other events, and one event that wears several different shapes.
order: 6
---

# Inner and variant events

Two ideas that don't exist in other calendars, and the reason Calendite can describe
schedules that other calendars force you to maintain by hand.

Both hang off an **Event Series**, the thing you think of as "an event": Work, Yoga,
Book Club. A series has a rule that decides which days it lands on.

---

## Inner Events: things that only happen inside other things

A stand-up at 09:15 on work days. Not "on weekdays": on **work days**. Bank holiday, no
stand-up. Late shift, the stand-up moves with it.

An **Inner Event** is a child series whose rule is implicitly intersected with its
parent's. It *cannot* occur on a day its parent doesn't. You don't write the intersection;
it's structural.

### Creating one

From an event's detail screen, **Add inner event**. You get the ordinary event form plus
one extra decision: how its timing relates to the parent.

| Timing | Behaviour |
|---|---|
| **Absolute** | a fixed clock time: 09:15, whatever the parent does |
| **Relative** | an offset: "15 minutes after it starts", "30 minutes before it ends" |

Relative is usually what you want for anything attached to a shift, because moving the
parent moves the child.

### Its rule

Leave the rule blank and the inner event rides **every** parent occurrence. Give it a rule
and it's intersected with the parent's, so `Mon` on a parent of `WD` means "Mondays that
are also work days".

### How it looks

Inner events don't compete with their parent for space. In the week view the bottom strip
of the parent block darkens and carries one pill per inner event, positioned proportionally
within the parent's span. In the day view the parent gets a "folder tab" and the inner
events sit inside it. On the parent's detail screen they appear as a miniature day-view of
the parent's window.

### Limits

- One level deep: an inner event can't have its own inner events.
- An inner event belongs to exactly one parent.
- Inner events never appear on their own in the calendar; they're always inside a parent.
- Inner events **do not inherit the parent's alerts**. The detail screen shows the parent's
  alerts for context, but nothing is scheduled from them; give the inner event its own.

---

## Variant Events: one thing, several shapes

You work Earlys, Lates and Nights. One job. One tag, one colour, one set of notes, but
three different sets of hours.

A **Variant Event** is a named variation of a series that differs in a few attributes and
shares the rest.

```
Work
├── Early Shift    06:00–14:00    Mon2, Wed2, Fri2
├── Late Shift     14:00–22:00    Tue2, Thu2
└── Night Shift    22:00–06:00    -1Sat
```

Usually the difference is times, but it can be location, alerts, colour, tag or visibility.

### Creating one

From the base event's detail screen, **Add variant**. You name it (*Late Shift*) and
override only what differs. Anything you leave alone is taken from the base.

Each variant carries its own rule, so it decides its own days.

### How base and variants interact

A variant supersedes the base **only on the days that variant itself fires**. Every other
day, the base still fires normally.

So a base of `WD` with a Night Shift variant on `-1Sat` gives you weekdays **and** the last
Saturday. The base is not switched off by the existence of variants.

If you want the variants to be the *whole* schedule, give the base a rule that produces
nothing on the days the variants cover, or don't give the base a rule at all.

### What inherits, and what doesn't

| | Behaviour |
|---|---|
| Title, times, duration, location, colour | **Snapshot at save.** Editing the base later does **not** update variants that already exist. |
| **Alerts** | **Live.** An alert added to the base afterwards does reach existing variants. A variant can also suppress a base alert or add its own. |
| **Tags** | Falls back to the base's tags if the variant has none of its own. |
| **Visibility** | Live: variants default to inheriting from the base per view. |

If you change a base event's hours and want the variants to follow, you have to edit them.

### Variants and inner events

A base event's inner events don't appear on days a variant fires: the base isn't running
that day, so its children aren't either. If a variant needs a stand-up, give the variant
its own inner event.

> There is an *"Applies to…"* selector on inner events for choosing which variants they
> apply to. It saves and displays your choice, but it doesn't change which occurrences
> appear yet; it has no effect today. Don't rely on it.

---

## Which one do I want?

| Situation | Use |
|---|---|
| Something that happens *during* a bigger thing | **Inner event** |
| The same commitment with different hours on different days | **Variant** |
| Two unrelated things | Two separate events |
| Same thing, different people/place, same hours | One event, edit the occurrence |

A rough test: if cancelling the parent should cancel it too, it's an **inner event**. If
it *is* the parent wearing different clothes, it's a **variant**.

---

## Terminology

The precise definitions live in the [glossary](/docs/reference/glossary.html): Event
Series, Event Instance, Inner Event, Outer Event, Variant Event, Base Event, Draft Event.

---

## Next

- [Repeating events](/docs/everyday-use/repeating-events.html): the rules these are built on
- [Reminders and alerts](/docs/everyday-use/reminders-and-alerts.html): what fires and when