Start with one complete event
Record the title, start, end, location, description, and time zone before generating the file. Every event also needs a stable UID so calendar applications can recognize updates to the same event instead of creating duplicates.
- Use an end time later than the start time.
- Keep the same UID when distributing a corrected version.
- Use plain, useful event text rather than pasting an entire formatted webpage.
Choose local time or UTC deliberately
Use a named time zone when the event should stay at the same local wall-clock time, such as a weekly 09:00 meeting. Use UTC when the event represents one fixed instant everywhere. A floating time with no zone can be interpreted differently by different applications.
Add recurrence without duplicating events
A recurring event normally uses one VEVENT with an RRULE rather than many copied VEVENT blocks. Preview the recurrence first, set an end with COUNT or UNTIL when appropriate, and test month-end or daylight-saving transitions.
Validate, import, and test an update
Validate required properties, line endings, folded lines, dates, and recurrence syntax before sharing the download. Import the file into a test calendar, then import a corrected file with the same UID to confirm the target application handles updates as expected.
Important ICS fields
| Field | Purpose | Common mistake |
|---|---|---|
| UID | Stable identity for the event | Generating a new value for every correction |
| DTSTART / DTEND | Start and end date-time | Mixing local time and UTC accidentally |
| DTSTAMP | When the calendar object was created or revised | Using it as the event start |
| RRULE | Recurrence pattern | Creating both an RRULE and duplicate events |