Turn an event list into a calendar file with AI
An event that looks right in chat can land on the wrong day in a calendar. The usual culprit is an all-day event that ends a day earlier than everyone thinks.
Example output
A calendar file with explicit event times
Fictional events: the clinic in UTC, and the all-day planning day ending on the following date.
Read the prompt
Create an iCalendar .ics file from the attached permitted event table.
Use the supplied named time zones and dates, not my device's assumed zone.
Ask about missing or ambiguous dates before generating an event.
Give each event a stable unique UID and preserve it when revising that event.
For each row, show the source start/end, the encoded start/end and whether
it is timed or all-day. Escape text correctly and use valid .ics line endings.
Do not add attendees, organisers, reminders or invitations unless supplied.
Return the actual file and the mapping table.What you'll make
an .ics calendar file that people can import in one go, with every event’s date, time and time zone checked against your list.
What you'll need
a table of events (title, date, start and end time or “all day”, and the time zone), an AI tool that can return a downloadable file (ChatGPT, Claude or Gemini) and a test calendar to import into. About 15 minutes. If the events are only for your own Google Calendar, its Import and Export settings also accept a CSV directly. An .ics file is the better choice when you’re sending events to other people, or to Outlook, which imports .ics files.
1. Settle every date before asking for the file
Make one row per event. Give timed events a start and end time and the place’s time zone, such as Europe/London. For all-day events, write the last day the event covers, in plain words. If the source says “next Thursday”, turn it into a date first.
Create an .ics calendar file from this event table: [table]
Use the time zone given for each event, not my device's.
Give each event a permanent unique ID (UID) and keep it if you revise the event later.
For each row, show me the date and time as written and as encoded in the file, and whether it's timed or all-day.
Don't add attendees, reminders or invitations. Ask me about any date that's unclear before you start.[table] is your event list, pasted or attached.
Why this works: the side-by-side “as written” and “as encoded” table is what you’ll check in step 2, and asking about unclear dates first stops the AI from guessing “next Thursday”.
What you should see: a downloadable .ics file and a table with one row per event.
2. Open the file and check the fields
Open the .ics file in a text editor and compare it with the table. Three fields matter most:
- DTSTART and DTEND are the start and end. A time ending in Z is UTC. On 12 November 2026, London is on UTC, so 13:00 London is
20261112T130000Z. - For an all-day event, DTEND is the day after the last day. An event covering 13 November has DTSTART
20261113and DTEND20261114. If DTEND is also 13 November, the file breaks the format’s rule that the end comes after the start, and calendars may show the event wrongly or not at all. - UID is each event’s permanent ID. Every event needs a different one.
Also check titles with commas or apostrophes, which need escaping in the file.
Check this .ics file against my event table. List any event that's missing, any duplicate UID,
any time without a Z or a time zone, and any all-day event whose end date isn't the day after its last day.
Check titles that contain commas, semicolons or line breaks.Why this works: these are the fields that look fine in a chat summary and break in a calendar.
What you should see: a short list of problems, or a clear “none found” for each check.
3. Test the import, then share it
Import the file into a test calendar first. In Google Calendar, click the gear, then Settings › Import and Export, choose the file and pick the test calendar. In Outlook on the web, go to Calendar › Add calendar › Upload from file. Check each event’s day, time and length on screen. An imported file is a one-off copy: if an event changes later, people need a new file, and some calendars may add a duplicate rather than update the old event, so test a re-import before you rely on it.
Why this works: the file check proves the encoding; the import shows what people will actually see.
What you should see: every event on the right day, at the right time, for the right length.
Check the result
- One event in the file for each row in your table.
- Every timed event has a Z or a named time zone.
- Every all-day event ends on the day after its last day.
- Every UID is different, and the test import shows the right days and times.
The usual failure: the all-day end date is the same as the start date. The AI writes DTEND 20261113 for a one-day event on 13 November, because “it ends on the 13th” sounds right. Spot it by comparing DTSTART and DTEND on every all-day event: they should never match.
Event [event] covers [last day]. Its all-day DTEND must be the following day, because the end date isn't included.
Fix that field, keep the event's UID and everything else the same,
and return a new file with a list of what changed.[event] is the event’s title or row; [last day] is the last date it covers.
Worked example: a clinic and a planning day
Fictional example. An office manager sends two November events to the team.
Title Date Time Time zone
Team AI clinic 12 November 2026 13:00–14:00 Europe/London
Planning day 13 November 2026 All day Europe/LondonFirst file (wrong): the clinic is 20261112T130000Z to 20261112T140000Z, which is right. The planning day has DTSTART 20261113 and DTEND 20261113.
Repair: the repair prompt above, with “Planning day” and 13 November.
Repaired file: the planning day is DTSTART 20261113, DTEND 20261114. The test import shows it as a full day on Friday 13 November.
- The clinic is right because London’s clocks went back on 25 October, so in November London time is UTC. In September, 13:00 London would be 12:00 UTC, ending
T120000Z. - The planning day’s error is the classic one. “Ends on the 13th” is true in words and wrong in the file.
- Both events kept their UIDs through the repair, so a revised file can refer to the same events.
Try it
Check the encoded dates
Specify time zones and event boundaries, then inspect actual import results.
Check the file's fields first, then a test import. All-day events end on the day after their last day.
The example in text
- 12 Nov 2026, 13:00–14:00 London
- 13 Nov all-day
- All-day end is 14 Nov exclusive
Task kit for this job: Download (ZIP) · Reusable instructions
Go deeper
Check the clock-change weeks
Events between late March and late October, or in the weeks when different countries change their clocks, need extra care. The time-zone guide shows how to check a time across a clock change before it goes into the file.
Keep a record of each version
Save the event table, the file and its UIDs together, with a version number. When an event changes, compare the new table with the old one before you make a new file, rather than assuming the same file name means the same events.
Ask for narrow fixes
When one event is wrong, ask the AI to fix that field only and list the change. Regenerating the whole file can quietly change other events, or their UIDs.