ICS alarm TRIGGER: before the start, after the end or at a fixed time?
A reminder at 09:45 can mean “15 minutes before a 10:00 meeting” or “at 09:45 UTC regardless of the meeting.” Those alarms look identical until the event moves. Read the trigger’s value type and reference point before diagnosing the reminder.
Illustrative event moved from 10:00–11:00Z to 11:00–12:00Z
| Trigger meaning | Before move | Calculated after move if trigger unchanged |
|---|---|---|
| START minus 15 minutes | 09:45Z | 10:45Z |
| END minus 15 minutes | 10:45Z | 11:45Z |
| END plus 5 minutes | 11:05Z | 12:05Z |
| Absolute 09:45Z on the specified date | 09:45Z | 09:45Z |
Find the reference point
RFC 5545 section 3.8.6.3 defines TRIGGER inside VALARM. Its default value type is DURATION, measured relative to the associated event’s start unless RELATED specifies otherwise. A negative duration is before that point; a positive duration is after it.
For a fictional event from 10:00Z to 11:00Z, TRIGGER:-PT15M means 09:45Z. TRIGGER;RELATED=END:-PT15M means 10:45Z, while TRIGGER;RELATED=END:PT5M means 11:05Z. A displayed offset is incomplete until you know whether it is relative to START or END.
Distinguish a fixed absolute trigger
TRIGGER;VALUE=DATE-TIME:20261102T094500Z specifies an absolute UTC instant. RELATED is not valid on that absolute form. If the meeting is moved from 10:00Z to 11:00Z, the absolute value still describes 09:45Z; a relative fifteen-minute-before-start rule would instead calculate 10:45Z from the new start.
The table shows calculated semantics, not a guarantee that an editor leaves absolute alarms unchanged during a reschedule. A provider may rewrite the alarm, so reopen the saved record before concluding what happened. On a recurring event, an absolute trigger describes that specified instant, with any explicit alarm repeats; it is not automatically a new alarm at that clock time for every occurrence.
Check that the necessary event fields exist
A start-relative trigger requires DTSTART in its parent. An end-relative VEVENT alarm requires DTEND or the combination of DTSTART and DURATION. A raw END offset without a defined event end is not enough information to calculate a valid target.
DATE-only events use a midnight reference in the user’s configured zone under the RFC, with a UTC fallback when none is found. A generic “before this all-day event” therefore needs more care than assuming an ordinary daytime appointment. Use the provider’s supported all-day alert controls for the result you actually need.
Separate the calculated trigger from notification delivery
VALARM also needs an ACTION; display alarms require their display text. A trigger property is not a whole alarm or proof that an operating system delivered it. Application support, permissions and notification delivery still need checking separately.
This guide does not promise that Cloud Calendars imports every alarm action or exposes raw START, END and absolute choices. Compare its saved alert settings and the owning provider, then use the notification troubleshooting guide if the calculation is correct but delivery fails.
What it looks like
Cloud Calendars overview, using our product images. Provider settings and protocol examples described in this guide are separate from the screens shown here.
What to do
- Identify the parent event’s start and end.
- Read VALUE and RELATED before interpreting the offset.
- Calculate the target time with the saved values.
- Check ACTION and app support separately from notification permission and delivery.
Questions
- Is TRIGGER:-PT15M relative to the end?
- No. The default reference is the start. RELATED=END explicitly selects the end.
- Does an absolute alarm automatically repeat with a weekly event?
- No. The RFC describes the specified absolute instant and any explicit alarm repeats, not an automatically recalculated weekly offset.