Before sharing an event, check its dated local start, named time zone and elapsed duration together. The result should identify one UTC start and one UTC end, with the correct date wherever the event is displayed.
This optional Part 4 guide gives you a working exercise and a test card for an event app you build in Overskill. Use it to review a calendar file and write a precise change request. For reservations, staff availability and appointment changes, start with the service-booking guide. For deadlines counted backward from an event date, use the event-materials calendar.
Check one event before sharing it
Make your event-time checker
Edit the complete local-only brief. Nothing from the checker or calendar file is added automatically.
The exercise uses fictional events and a pinned 2026c historical timezone baseline. It supports organizer dates in 2026–2027, whole elapsed durations of 1–1440 minutes, and four zones: America/New_York, Europe/London, Asia/Kolkata and Australia/Sydney. It is a bounded teaching example. It does not claim the latest rules or replace checking current timing for a real event. IANA explains that timezone data changes as authorities change offsets, boundaries and daylight-saving rules. IANA Time Zone Database
Choose a fictional case, then inspect or edit its title, organizer date, time, zone and duration. The checker calculates locally. It does not reserve time, contact attendees or save these inputs to an account. Leaving or reloading resets the example; moving between this page's sections keeps your work.
The result has three possible states:
| Result | What to do before review |
|---|---|
| One matching instant | Inspect the UTC start/end and all four local dates and times. |
| This local time does not exist | Choose a different start. The checker cannot export a skipped local time. |
| This local time happens twice | Choose the earlier or later occurrence explicitly, using its UTC instant and numeric offset. |
Rejecting a missing time and requiring a choice are this checker's deliberate input rules. They are not RFC 5545's default interpretation of local times with a timezone reference. This exercise resolves the choice first and writes UTC values to the file. RFC 5545, date-time values
Read the date as well as the clock
Load Ordinary — New York. The fictional workshop starts on October 28, 2026 at 19:00 in New York and lasts 60 elapsed minutes. Under this exercise's pinned rules, its UTC interval is October 28 at 23:00 through October 29 at 00:00.
Scroll horizontally to compare all columns.
| Named zone | Local start | Local end |
|---|---|---|
| America/New_York | Oct 28, 19:00 · UTC−04:00 | Oct 28, 20:00 · UTC−04:00 |
| Europe/London | Oct 28, 23:00 · UTC+00:00 | Oct 29, 00:00 · UTC+00:00 |
| Asia/Kolkata | Oct 29, 04:30 · UTC+05:30 | Oct 29, 05:30 · UTC+05:30 |
| Australia/Sydney | Oct 29, 10:00 · UTC+11:00 | Oct 29, 11:00 · UTC+11:00 |
All four rows describe the same interval. Kolkata and Sydney begin on the following date; London's end crosses midnight. Keep these dates visible when you compare your app's event page, confirmation screen and file.
Now load Repeated hour — New York. November 1, 2026 at 01:30 has two candidates in this baseline. With the example's 90-minute duration:
Scroll horizontally to compare all columns.
| Explicit choice | UTC start | UTC end | New York end |
|---|---|---|---|
| Earlier, UTC−04:00 | Nov 1, 05:30 | Nov 1, 07:00 | Nov 1, 02:00 · UTC−05:00 |
| Later, UTC−05:00 | Nov 1, 06:30 | Nov 1, 08:00 | Nov 1, 03:00 · UTC−05:00 |
For the earlier choice, 90 elapsed minutes advances the displayed clock from 01:30 to 02:00 because the offset changes. Calculate duration on the UTC timeline. Do not derive it by subtracting the two displayed local clock readings.
The end marks the instant the event stops. A 19:00–20:00 event does not include an extra minute after 20:00. This matches iCalendar's non-inclusive DTEND. RFC 5545, event component
Review the current inputs before exporting
Choose Review this event after checking the selected instant, title and description. A reviewed file receives an event identity and a UTC revision time. Repeated downloads of that reviewed artifact keep the same identity, timestamp and bytes.
Every event edit clears the current file, including an edit that you immediately reverse. Changing the date, time, zone or duration also clears a repeated-hour choice. Select the intended occurrence again before reviewing. Blank or invalid inputs stay unresolved; they do not silently become your device's timezone or an assumed duration.
If a second review happens within an already-used clock second, the checker asks you to wait briefly and review again. It does not invent a later timestamp. The file uses DTSTAMP as the revision time of its informational component. RFC 5545, date-time stamp
A new review after an edit produces a separate demonstration artifact. It does not update or cancel something previously imported into a calendar. Keep the earlier file clearly separate when comparing changes.
Check the saved file separately from the screen
Choose Download reviewed .ics, then confirm that the browser saved a file. A download request alone does not establish that the file reached your downloads folder. Copy calendar text and Select text provide a readable fallback; clipboard line endings may differ from the exact downloaded bytes.
The exercise writes one event with UTC DTSTART and DTEND, an identifying PRODID, UID, DTSTAMP, title and description. It uses UTF-8, CRLF line endings, escaped text and lines folded at no more than 75 octets without splitting a Unicode character. RFC 5545, content lines and text values
Use the calendar-time test card to record three separate results:
| Check | Evidence to keep |
|---|---|
| Reviewed meaning | Organizer input, explicit occurrence choice where needed, UTC start/end and all four local displays. |
| Saved artifact | The actual .ics file, its decoded title/description and start/end, plus an identical repeat download from the same review. |
| Calendar compatibility | A result from your intended calendar's supported parser or import preview, if available. Leave it unverified until checked. |
The exercise does not perform a calendar import. Its file contains no invitation method, attendee list, organizer property, alarm or recurrence. Opening the file in another app may offer to create an event; that is a separate action. A readable file does not prove acceptance by every calendar.
Turn the checks into an Overskill change request
Overskill's first-app walkthrough explains the describe, preview and refine path. Use the brief below to request a small event-time workflow, then run the same cases against the resulting app. The requirements are instructions for your build, not a claim that every generated event app already implements them.
Start with fictional event details and no account writes. If a later version saves published events, define organizer-only edits and public access to published event fields separately. Keep participant names, email addresses and private notes out of public responses and calendar files, and verify those restrictions on the server.
Build a public event-time checker for community organizers.
First useful journey: enter one local event start, select its named zone,
resolve any repeated-hour choice, inspect four dated local start/end views,
then review and download one informational calendar file.
For the first exercise, use America/New_York, Europe/London, Asia/Kolkata
and Australia/Sydney; organizer dates in 2026–2027; and 1–1440 whole elapsed
minutes. Identify the actual timezone-rule version. The supplied exercise
uses pinned 2026c historical data; do not label runtime rules as 2026c.
Reject blank, invalid, unsupported and nonexistent local times.
Require an explicit earlier/later choice for repeated times.
Calculate the end from the selected UTC start plus elapsed minutes.
Show the full date, local time, numeric offset and named zone.
Invalidate the reviewed file on every edit, even an edit-and-revert.
Timing changes clear the occurrence choice, including changes without an
input event. Review again before copying or downloading. Keep repeat
exports of one review byte-identical. A new review is a separate artifact,
not an update or cancellation of an imported event.
Keep this first checker local: no visitor-data storage, network submission,
calendar connection, bookings, messages, payments or invitations.
Show readable calendar text when copying or downloading is unavailable.
Test the saved file, Unicode text, eight supplied timezone cases, keyboard,
phone layout, navigation and stale-output handling. Report unverified tests.
If persistent events are added later, require authorized organizer edits
on the server. Visitors may read only published public event fields.
Exclude participant details and private notes from public reads and exports.
Prove that a visitor and a different organizer cannot change another event
or read its unpublished/private data before enabling that saved-data flow.
Adapt these requirements with the event-time build brief. Review the current prompt before choosing Start build; Copy brief is the secondary option. The checker does not automatically transfer your event inputs or file into that prompt. Start build saves the brief in Overskill and continues through sign-in when needed; normal access and credit requirements apply. A saved brief is separate from a generated, tested app.
For an event-site starting point, the Rally template catalog describes an event page and a volunteer signup flow with an .ics file. That catalog description does not establish its timezone behavior or file correctness. Inspect an authorized copy and apply this test card before relying on its export. No signup, calendar import or booking is needed to use the exercise here.