Why an ICS all-day event ends one date after its last visible day
An all-day ICS event ending at 20261105 can correctly describe a trip whose last day is 4 November. The ending date is a boundary, not necessarily a day to display. This guide explains how to inspect that boundary without moving the real trip.
Illustrative DATE boundaries
| Intended visible dates | DTSTART value | Exclusive DTEND value |
|---|---|---|
| 2 November only | 20261102 | 20261103 |
| 2–4 November | 20261102 | 20261105 |
| 30 November–2 December | 20261130 | 20261203 |
Use calendar dates, not midnight timestamps
RFC 5545 section 3.6.1 defines DTSTART as included and DTEND as excluded for a VEVENT. When the start uses the DATE value type, an explicit end must also use DATE. A record beginning DTSTART;VALUE=DATE:20261102 and ending DTEND;VALUE=DATE:20261105 covers 2, 3 and 4 November. It stops before 5 November begins.
A value such as DTSTART:20261102T000000Z describes a timed instant in UTC. It is not interchangeable with DTSTART;VALUE=DATE:20261102. Converting one representation into the other can introduce a time-zone question that the original date-only label did not have.
Work through the boundary before editing
Imagine a fictional three-day exhibition from Monday 2 November through Wednesday 4 November 2026. Write those three included dates first. The corresponding excluded end boundary is Thursday 5 November. A file showing that later boundary is therefore consistent with the brief, not proof of an extra day.
For a one-day entry on 2 November, an explicit DATE end is 3 November. The RFC also defines a one-day duration when a DATE start has neither DTEND nor DURATION. Do not add a second visible date merely because the end property is absent.
Compare the export with the displayed result
Keep the original file and compare the first and final included dates in a separate disposable destination calendar where the provider supports imports. Check the next date too. The expected result for the exhibition is a label on 2–4 November and no label on 5 November.
If a destination actually displays the extra date, record its name, import route and the exact DATE fields. Do not subtract one day from every export as a general repair. An incorrect start, a timed representation or an importing application’s interpretation can require a different fix.
Keep format semantics separate from Cloud Calendars controls
This page explains the iCalendar interchange format. It does not provide a raw ICS editor in Cloud Calendars or claim identical import behavior across providers. Use the owning service’s supported import and editing tools, then inspect the resulting dates in the calendar view.
The existing all-day planning guide covers the app’s date selection, availability and widget eligibility. This technical check answers the narrower question of what a DATE-valued DTEND in an exchanged file means. A displayed date range and a free/busy decision remain separate checks.
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
- List the intended included dates.
- Confirm that the fields use VALUE=DATE rather than timed values.
- Treat DTEND as the first excluded date.
- Compare the displayed start, final included day and following day without deleting the original.
Questions
- Should I remove a day from the ICS end date?
- Not just because the raw date looks later. An exclusive boundary is correct when the destination displays the intended included dates.
- Is an all-day entry the same as a midnight appointment?
- No. A DATE value and a DATE-TIME value have different meanings. Retain the representation that matches the actual commitment.