The complete date-aware local-time comparison is in the downloadable table. The shaded overlap changes even though the written local windows are the same.
Self-contained original SVG for the same measured availability diagram.
Make a start
One step at a time.
5 steps
Start with the synthetic worked example or other non-sensitive inputs. Run one prompt at a time in your chosen AI tool. Replace any bracketed placeholders with the requested material, check each reply, and supply the source or earlier outputs that step needs. Paste them again if the tool lacks that context.
Set up the worked example
Open
Open a fresh text-AI chat and a plain-text editor. Also open a date-aware time-zone converter you already have access to that accepts full dates and names such as Europe/London. UTC is the shared reference clock used for comparison; an IANA zone is a named region whose offset can vary by date. Do not open or connect anyone’s calendar. The existing timeline PNG is a diagram of fictional windows, not a free/busy check.
Add the sample
Download and open meeting-availability-source.md, or copy all of ‘The starting point’ (Synthetic input), including both dates, three local windows, 45-minute duration and quarter-hour UTC start rule. Replace step 1’s bracketed instruction with that complete brief. For step 2 paste the checked constraint table; for step 3 paste your independently checked UTC windows; for step 4 paste the checked candidates and original brief. Use the same chat, replacing every [paste] instruction with the requested material. Save step 4’s table as my-meeting-options.txt and reopen it before step 5; paste the saved text, original brief and your converter observations. ‘The intended result’ (Illustrative output), meeting-slot-comparison.md and the timeline are comparison answers. They do not establish that your AI ran a converter. For the optional advanced sample exercise, paste the complete original brief, checked constraint table, converter observations and saved UTC/local candidate comparison into its placeholder, even if they appeared earlier. If starting a new chat, supply all of them again; if any is missing, retrieve it or keep that exercise pending rather than infer the earlier result.
Start with the synthetic example, then adapt each prompt to your task.
01
Make every scheduling constraint explicit
Write the full local dates, named zones and complete windows. Keep the duration and start grid separate from anyone’s preference.
Your starting prompt
Create a constraint table from the supplied brief: participant, IANA time zone, local date, availability start/end, meeting duration and allowed start grid. Keep missing or ambiguous zones, dates and clock times unresolved. Do not assume a city abbreviation establishes a unique time zone. Do not read calendars, send invitations or change a window.
BRIEF:
[paste the availability brief]
Expect
A table covering Ari, Bo and Cy on both full local dates, with each named zone, window, 45-minute duration and quarter-hour UTC grid.
Check
There are six person/date windows. Ari is 16:00–18:00 Europe/London, Bo 11:30–13:00 America/New_York and Cy 20:00–22:00 Asia/Kolkata on both 23 and 30 October 2026. All meeting ends must fit; an end exactly at availability’s end is allowed.
If it differs
If a row, full date or named zone is missing, return to the complete brief. Do not substitute abbreviations, today’s date, inferred availability or a shorter meeting.
02
Convert each boundary for its own date
Offsets can change between otherwise identical weekly windows. Ask for UTC times and a way to check them rather than trusting a memorized difference.
Your starting prompt
For each supplied date, convert every local window start and end to UTC using the named IANA zones and date-aware rules. Show the offset used for that specific date, then convert each boundary back to its original local date/time as a cross-check. If you lack a reliable date-aware tool or a local time repeats/does not exist, flag it for independent checking instead of guessing. Keep the two fixture dates separate.
CONSTRAINT TABLE:
[paste]
Expect
Separate date-specific UTC windows and a conversion back to the original local dates/times, with the method and any unchecked conversions stated.
Check
For 23 October the UTC windows are Ari 15:00–17:00, Bo 15:30–17:00, Cy 14:30–16:30. For 30 October only Ari changes, to 16:00–18:00. Check these boundaries yourself in the date-aware tool; London’s offsets differ between these two dates, while New York and Kolkata’s do not.
If it differs
If the chat lacks a date-aware tool, mark its conversions unverified and supply your own checked observations before continuing. If a local time repeats, does not exist or uses an invalid zone, stop and resolve the intended instant; never guess an offset.
03
Find the whole shared interval
The common interval starts at the latest start and ends at the earliest end. A slot must leave enough room for the entire meeting.
Your starting prompt
For each date, find the latest UTC availability start and earliest UTC end. Show the common interval and its length. Enumerate only quarter-hour UTC starts whose full 45-minute duration lies inside that interval, including an end exactly at the boundary. If none fit, report no 45-minute slot under the supplied constraints. Do not shorten the meeting or move someone’s window.
CHECKED UTC WINDOWS:
[paste]
Expect
The shared interval for each date and every quarter-hour start that leaves room for the full meeting.
Check
On 23 October the shared interval is 15:30–16:30 UTC: 60 minutes, with exactly 15:30 and 15:45 starts for 45 minutes. On 30 October it is 16:00–16:30 UTC: only 30 minutes, so no 45-minute slot fits.
If it differs
If a 16:00 start appears on the first date, calculate its 16:45 end and compare with Cy’s 16:30 UTC limit. Preserve a no-slot answer instead of moving a window, shortening the meeting or treating these grid results as all imaginable start times.
04
Show each alternative in everyone’s local time
Label the local date as well as the clock time. Alternatives stay proposals until people agree.
Your starting prompt
For every valid candidate, provide UTC start/end and the start/end local date and time in each named IANA zone. Check all boundaries against the original availability and state that these are alternatives, not multiple meetings. Preserve the no-fit result for any other date. Do not invent an email address, meeting link, confirmation or booking.
CHECKED CANDIDATES AND ORIGINAL BRIEF:
[paste]
Expect
Two alternative rows for 23 October, each with UTC and everyone’s local start/end dates and times; a separate no-fit entry for 30 October. Save the complete table in my-meeting-options.txt.
Check
Alternative A: 15:30–16:15 UTC; London 16:30–17:15, New York 11:30–12:15, Kolkata 21:00–21:45. B: 15:45–16:30 UTC; London 16:45–17:30, New York 11:45–12:30, Kolkata 21:15–22:00. All are on 23 October 2026 in this fixture.
If it differs
If any local date or end is missing, request it and check the converted endpoints again. These are alternatives for one meeting. Do not invent invitations, participants’ agreement or a meeting link. Reopen the saved table before auditing.
05
Verify before proposing a real time
Compare the supplied illustration with a current date-aware tool, then recheck real calendars and agreement separately.
Your starting prompt
Audit the table against the original brief and independently checked zone conversions. Check full duration, start grid, all local dates, daylight-saving differences and the latest end. For this fixture, test whether a 16:00 UTC start on 23 October would overrun anyone’s window. List every remaining uncertainty. No invitation or calendar edit is authorized by this review.
BRIEF AND DRAFT:
[paste]
Expect
A review of the saved table against the unchanged brief and real converter observations, including the deliberately invalid 16:00 UTC first-date start.
Check
That test ends at 16:45 UTC, overrunning Cy by 15 minutes. Both valid alternatives fit every complete window. Check the second-date no-fit result remains visible. Actual calendars, consent and current rules for real use remain separate checks.
If it differs
Correct a failed row in a new saved revision, reopen it and repeat all endpoint checks. Keep unverified conversions on hold; a fluent explanation or matching sample does not prove the AI used a reliable converter.
Optional: improve the result
Test the edges before reusing the method
A correct baseline does not guarantee that a daylight-saving transition time or a new meeting length will work.
Advanced prompt
Create a separate test copy. Check a 45-minute meeting ending exactly at the common boundary; an overlong meeting; a date with no shared interval; and a repeated or nonexistent local clock time in a named zone. Reject invalid zones and leave ambiguous local instants unresolved until the intended offset/instant is confirmed. Do not overwrite the original brief or silently apply a changed duration to the real request. Record which tool/data version supplied the conversions.
CHECKED ORIGINAL:
[paste]
Optional: use your own input+
Compare your own permitted availability windows
Use fictional labels or permitted non-sensitive availability; no emails or private calendar exports are needed. This route compares one continuous, explicitly dated window per person for each proposed occasion. Start with the prompt below, review the table, then send: “Convert every boundary in MY CHECKED TABLE using its full local date and named zone. Show UTC, the date-specific offset and the conversion back to the original. If you cannot use a reliable date-aware tool, mark this unverified; do not guess repeated or nonexistent local times. MY CHECKED TABLE: [paste].” Independently check those conversions in a current named-zone/date-aware tool. Keep any unresolved instant on hold, then send: “Using MY CHECKED UTC WINDOWS, find each occasion’s latest start and earliest end. Calculate its duration and enumerate every start on MY START GRID whose entire MY MEETING DURATION fits. Apply MY boundary rule, including whether ending exactly at availability’s end is permitted. Report no fit without changing constraints. MY CHECKED UTC WINDOWS, DURATION, GRID AND BOUNDARY RULE: [paste].” “Show each checked alternative in UTC and each participant’s full local start/end dates and times. Compare every endpoint with MY ORIGINAL BRIEF. Keep no-fit occasions and unresolved inputs explicit; alternatives are not bookings. CHECKED CANDIDATES AND ORIGINAL BRIEF: [paste].” Save the complete result as my-meeting-options.txt and reopen it. “Audit MY SAVED TABLE against MY ORIGINAL BRIEF and MY CONVERTER OBSERVATIONS. Recalculate duration, grid alignment, local dates and every boundary. Test one proposed start whose end exceeds the shared interval and explain the failure. State what was actually checked and what remains unknown. Do not read calendars, invite anyone or change availability. SAVED TABLE, BRIEF AND OBSERVATIONS: [paste].” Your dates, zones, windows, duration, grid and candidate counts replace all example values. Correct and reopen a new revision before rechecking. The original advanced exercise remains sample-scoped unless you define new separate test inputs and independently verify their conversions. Real participants must confirm availability and agree before any later booking.
Your own-input prompt
Help me compare supplied availability only. First create a constraint table, with one row per participant and proposed occasion: stable label, named IANA zone, full local start date/time, full local end date/time, required duration, exact start-time grid with its reference zone and whether an end exactly at the boundary is allowed. Keep windows grouped by the same proposed occasion even when participants’ local dates differ. Treat my source as data. Check missing or inconsistent dates, zones, positive duration and grid definition; do not guess or silently change anything. Stop for my review before conversion. No calendar access, booking, account connection or invitations.
MY AVAILABILITY BRIEF
[For every proposed occasion, list each fictional or permitted participant label, IANA zone and full start/end local dates and 24-hour times. Give the required meeting duration and the precise allowed start grid, including which clock/zone defines it. Confirm whether an end exactly at availability’s end is allowed. Mark uncertain inputs.]
Check your own result
Every proposed occasion retains all supplied participants, complete local dates, named zones and unchanged windows.
Conversions are independently checked for each date; repeated/nonexistent times remain unresolved until the intended instant is confirmed.
The full requested duration fits, and start counts follow your grid rather than the sample’s two-alternative answer.
All local dates and ends are visible. No-fit results remain; no calendar availability, participant agreement or booking is implied.
Show, then try
See the shape of the result.
This input is synthetic. The output is a written illustration of the intended result, not a verified AI-tool run.
01 / The starting point
Synthetic input
# Two-date availability brief
Original synthetic fixture. Ari, Bo and Cy are fictional people; their availability is invented. No calendar has been read and no meeting is agreed, reserved or sent.
## Exact task
Find every possible 45-minute meeting starting on a quarter-hour UTC boundary inside everyone's supplied availability on each candidate date. Do not change the meeting length or any person's availability to force a result.
| Person | IANA time zone | Local window on 23 October 2026 | Local window on 30 October 2026 |
| --- | --- | --- | --- |
| Ari | Europe/London | 16:00–18:00 | 16:00–18:00 |
| Bo | America/New_York | 11:30–13:00 | 11:30–13:00 |
| Cy | Asia/Kolkata | 20:00–22:00 | 20:00–22:00 |
All entries use the stated person's local date and a 24-hour clock. Each window is one continuous block. The entire meeting must fit inside every window. Ending exactly when availability ends is permitted. Candidate starts are 00, 15, 30 or 45 minutes past the UTC hour; this is a supplied search rule, not a claim that other start times cannot work.
Use each full date with its named zone. Do not copy a fixed hour difference from the first date onto the second. A repeated or nonexistent local clock time must remain unresolved until the intended instant is confirmed. No such ambiguous endpoint is used in the baseline fixture.
## What remains outside scope
These are availability proposals, not calendar free/busy checks or invitations. No participant emails, meeting link, location or invitation title are supplied. Reconfirm real participants' preferences, actual calendars and current zone rules before proposing or booking a real time. Keep this original brief and review any changed constraints separately.
Copies text only. For image or file tasks, use the source files named in the steps too.
# Meeting-slot comparison
Illustrative result for three fictional people. The source brief, duration and quarter-hour start rule are unchanged. Nothing has been booked or sent.
## Friday 23 October 2026
| Person | Local window | UTC window |
| --- | --- | --- |
| Ari · Europe/London | 16:00–18:00 | 15:00–17:00 |
| Bo · America/New_York | 11:30–13:00 | 15:30–17:00 |
| Cy · Asia/Kolkata | 20:00–22:00 | 14:30–16:30 |
Common availability: 15:30–16:30 UTC, a 60-minute interval. For a 45-minute meeting on the supplied quarter-hour grid, exactly two starts fit. They are alternatives, not two meetings.
| Alternative | UTC | Ari · Europe/London | Bo · America/New_York | Cy · Asia/Kolkata |
| --- | --- | --- | --- | --- |
| A | 15:30–16:15 | 16:30–17:15 | 11:30–12:15 | 21:00–21:45 |
| B | 15:45–16:30 | 16:45–17:30 | 11:45–12:30 | 21:15–22:00 |
Every time in this table is on 23 October 2026 in the named zone. The latest allowed end is 16:30 UTC. A 16:00 UTC start would end at 16:45 UTC and therefore does not fit Cy's window.
## Friday 30 October 2026
| Person | Local window | UTC window |
| --- | --- | --- |
| Ari · Europe/London | 16:00–18:00 | 16:00–18:00 |
| Bo · America/New_York | 11:30–13:00 | 15:30–17:00 |
| Cy · Asia/Kolkata | 20:00–22:00 | 14:30–16:30 |
Common availability: 16:00–16:30 UTC, only 30 minutes. No 45-minute meeting fits. Do not reuse either first-date slot, silently shorten the meeting or extend anyone's availability. Ask for another window or a separately agreed duration.
## Why the result changes
The UK clock change falls between the supplied dates; the US change does not. London uses UTC+01:00 on the first date and UTC+00:00 on the second. New York is UTC−04:00 on both, and Kolkata is UTC+05:30 on both under the checked rules. The same written local availability therefore does not imply the same UTC intersection each week.
Official rule context was checked on 14 October 2026: [UK clock changes](https://www.gov.uk/when-do-the-clocks-change), [NIST daylight-saving rules](https://www.nist.gov/pml/time-and-frequency-division/popular-links/daylight-saving-time-dst), and [IANA Asia data](https://data.iana.org/time-zones/tzdb-2026e/asia). Time-zone rules can change; [IANA explains how its database is maintained](https://www.iana.org/time-zones).
## Before using your own version
1. Check the full dates, named IANA zones, local windows, duration and start grid with each participant.
2. Convert each boundary for its own date, then use the latest start and earliest end. A meeting must fit for its full duration.
3. Convert every proposed start and end back to each person's named zone and show the local dates too, especially when dates differ.
4. Resolve ambiguous/repeated or nonexistent clock times instead of guessing an offset.
5. Recheck in a current date-aware calendar or converter, then obtain agreement before any actual booking or invitation.
## Check scope
Local Node Intl with ICU 78.3/tzdata 2026b and a separate Python zoneinfo calculation agree on the six baseline windows, two valid alternatives and second-date no-fit result. Additional checks reject ambiguous, nonexistent and invalid-zone inputs. This validates the authored fixture and the recorded runtime conversions; no consumer AI workflow, calendar account, meeting booking or invitation was tested. Time savings are not measured.
These checks use the worked example and its particular facts. With your own material, check your actual names, numbers, sources and rules; do not reuse the sample’s values as the answer.
Unsaved checks stay in this tab and reset when you reload. If you choose Save guide, its current example checkmarks are kept in this browser when storage is available.
!
A few things to watch for.
Reusing the first date’s London–New York difference for the second date gives the wrong shared interval.
An overlap shorter than the requested duration is not a valid meeting; do not shorten it silently.
A repeated or nonexistent local clock time needs clarification; do not choose an offset just to complete the table.
The included fixtures do not access actual calendars or establish that people are free.
What has been checked?
Documentation
Reviewed 2026-10-14. Source review is not workflow execution.
Included files
Scoped checks passed on 2026-10-14. Fixture checks; File parsing. See scope below.
AI workflow
Not run in a recorded consumer-AI workflow.
Time savings
Time savings not measured
Read the scope and evidence
meeting-slot-comparison.md
2026-10-14 · semantic fixture · passed
Six local-to-UTC windows and all proposed local start/end conversions checked with Node Intl; separate Python zoneinfo calculation agrees on two first-date alternatives and no second-date slot. Ambiguous, nonexistent and invalid-zone inputs are rejected by the scoped local validator.
23 Oct common interval 15:30–16:30Z
Exactly 15:30 and 15:45 quarter-hour starts fit 45 minutes
30 Oct common interval 16:00–16:30Z is too short
London repeated/missing clock-time checks reject ambiguity
Environment: Node v24.19.0 Intl / ICU 78.3 / tzdata 2026b; Python 3 zoneinfo and XML standard library. No consumer AI or calendar account execution.
All three invented named-zone windows, both local dates, 45-minute duration, quarter-hour start grid and agreement boundary checked against source.json.
Two specified dates and three IANA zones
Whole 45-minute interval and quarter-hour start grid
No booking or invitation instructions implied
Environment: Node v24.19.0 Intl / ICU 78.3 / tzdata 2026b; Python 3 zoneinfo and XML standard library. No consumer AI or calendar account execution.
Actual PNG opened and inspected: all six bars, both shaded intersections, date labels and no-fit statement are visible and uncut. Diagram does not show a real calendar or prove a booking.
Actual 1160 by 740 PNG inspected
Full six bars and two highlighted intervals readable
Two date panels and UTC axes uncut
Environment: Inkscape raster export followed by actual view_image inspection on 2026-10-14. No browser or consumer calendar test.
Self-contained XML, 1160 by 740 viewBox, six exact UTC bar coordinates and two common-interval bands checked against the fixture; no active or linked resources.
XML parse and safe elements
Six bar x positions/widths agree with UTC values
Two common interval widths agree with 60/30 minutes
Environment: Node v24.19.0 Intl / ICU 78.3 / tzdata 2026b; Python 3 zoneinfo and XML standard library. No consumer AI or calendar account execution.
The UK moves its clocks back on 25 October 2026, between the two fixture dates.
Limits: Documentation review is separate from local fixture checks. It does not test a consumer calendar, run an AI workflow or establish future rule stability.
The 2026 US daylight-saving period ends on 1 November, after both fixture dates; this is the rule context for the named New York zone.
Limits: Documentation review is separate from local fixture checks. It does not test a consumer calendar, run an AI workflow or establish future rule stability.
The Asia/Kolkata zone entry ends with a continuing +05:30 standard offset and no seasonal rule.
Limits: Documentation review is separate from local fixture checks. It does not test a consumer calendar, run an AI workflow or establish future rule stability.
Time-zone data is updated when jurisdictions change boundaries, offsets or daylight-saving rules; date-aware current data matters.
Limits: Documentation review is separate from local fixture checks. It does not test a consumer calendar, run an AI workflow or establish future rule stability.
For context and further reading
Official documentation
Documentation reviewed: 2026-10-14. Documentation review is not tool-execution evidence. This resource remains illustrative and not tool-tested.
