I work on OnePassApps, so this is our own app - every number below came out of the live build at app.onepassapps.com/apps/time-zone-planner on 7 November 2026, in one signed-out browser session, with the panel in front of me.
My two earlier posts on this route covered the two-place plan (London and New York, the date-dependent offsets, the overnight window and the both-ends check) and then the reference-place swap with the out-of-range meeting length. Both of them ended by saying the same thing: they did not add a third place, so they made no claim about places with half-hour or 45-minute offsets. That is the gap this post closes.
Try it yourself: the Time Zone Planner or read the guide to finding a meeting time across time zones first. No account, no card, and it runs in the tab you are reading this in.
A third place with a 45-minute offset
The search field filters as you type and offers one row per match, so I added Chatham - Pacific/Chatham - and the card reads:
Pacific/Chatham · GMT+13:45 · UTC+13:45
Three-quarters of an hour, written out twice, in the zone abbreviation and in the explicit UTC value. The plan header moved from "2 places · 1 h meeting" to "3 places · 1 h meeting" and the panel printed "Chatham added."
With a 15:00 London meeting, the table row for Chatham is not a whole hour:
| Place | Local time | |
|---|---|---|
| London · GMT · UTC | 15:00–16:00 | 2026-11-07 |
| New York · GMT-5 · UTC-5 | 10:00–11:00 | 2026-11-07 |
| Chatham · GMT+13:45 · UTC+13:45 | 04:45–05:45 | 2026-11-08 (+1 day) |
The day moves as well as the clock: Chatham's date is the next one, marked "(+1 day)", and the meeting lands at 04:45 in the morning. Chatham's row is also the first one carrying the panel's "Outside working hours" marker - the panel's own rule is that "Hours are checked at both ends of the meeting", so a 04:45 start falls outside that place's working window. I did not change any place's start and end times, so I am not quoting their values here.
The same thing happens with a half-hour zone. I added Adelaide - Australia/Adelaide - and its card reads "Australia/Adelaide · GMT+10:30 · UTC+10:30", with the meeting at 01:30–02:30 on 2026-11-08 (+1 day). So the quarter-hour and half-hour offsets are not rounded off anywhere in the table.
The shared-hours line is where a third place bites
With London and New York alone, the overlap line read "Shared working hours: 14:00–17:00 London" - a real three-hour window.
The moment Chatham joined, the same line read "No time when everyone is inside their working hours on this date." Not a shorter window: no window at all. A 15:00 London slot is 04:45 in Chatham and 10:00 in New York, so the two-hour New York window and the nine-hour Chatham window never touch.
That line stayed exactly the same when I added Tokyo, Sydney, Auckland and Adelaide on top - five places beyond the reference, six of the seven in the plan. The panel does not narrow the answer as the plan grows; it stops having one.
The cap is eight places, and the message is exact
The guide says a plan holds two to eight places. The panel agrees, and it says so at the moment it matters. Adding Honolulu as the eighth place worked - the header read "8 places · 1 h meeting" - and the search field was replaced by:
You can compare up to 8 places. Remove one to add another.
At that point typing another city name produced no row to add at all: the search box no longer offered one. Removing a place brought the box straight back. Each card carries its own remove button - "Remove London", "Remove New York", "Remove Chatham" and so on - so I removed Tokyo and the panel printed "Tokyo removed.", the header dropped to "7 places · 1 h meeting", and the field returned with its original hint, "Search by city or zone name, for example Lisbon or Asia/Tokyo."
The search field also refuses a name that does not exist. Typing "Xyzzy" answered "No matching time zone. Try a nearby city or the zone name."
Swapping the reference to a half-hour zone
Every place except the reference has a "Use as reference" button. I made Adelaide the reference, and the plan header changed from "London day, 2026-11-07" to "Adelaide day, 2026-11-07". The same 15:00 start was then read against Adelaide's clock, and every row moved - including across midnight for New York:
| Place | Local time | |
|---|---|---|
| Adelaide · GMT+10:30 · UTC+10:30 | 15:00–16:00 | 2026-11-07 |
| Tokyo · GMT+9 · UTC+9 | 13:30–14:30 | 2026-11-07 |
| Sydney · GMT+11 · UTC+11 | 15:30–16:30 | 2026-11-07 |
| Auckland · GMT+13 · UTC+13 | 17:30–18:30 | 2026-11-07 |
| Chatham · GMT+13:45 · UTC+13:45 | 18:15–19:15 | 2026-11-07 |
| London · GMT · UTC | 04:30–05:30 | 2026-11-07 |
| New York · GMT-5 · UTC-5 | 23:30–00:30 | 2026-11-06 to 2026-11-07 (-1 day) |
Chatham is 18:15 in Adelaide, not a whole hour, and New York is on the previous date - the panel spells that out as "-1 day" and spans the two dates.
The .ics file, byte by byte
Pressing "Download .ics" wrote meeting-2026-11-07.ics - 946 bytes with seven places in the plan, and 804 bytes on an earlier export with six. The file is CRLF-terminated and starts the way you would expect:
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//OnePassApps//Time Zone Planner//EN
BEGIN:VEVENT
UID:62a1acbe-bc5e-4edd-ba9a-3bdfb5bafb96@onepassapps
DTSTART:20261107T150000Z
DTEND:20261107T160000Z
SUMMARY:Meeting
The start and end are UTC instants - 15:00 to 16:00 UTC - and there is no VTIMEZONE block at all, so a calendar client resolves the zone from its own copy. The UID is a fresh UUID on each export: the seven-place file carried one, the six-place file a different one.
The long part is the DESCRIPTION, and it is where the file gets interesting. RFC 5545 asks for content lines to be no longer than 75 octets, and the exporter folds there - in the seven-place file every folded line of the DESCRIPTION is exactly 75 bytes. The catch is that the fold counts octets, and the file uses UTF-8: the en dash in "15:00–16:00" is three bytes, so a line with one of them holds 71 characters, and a line with two holds 73. The line lengths therefore alternate between 71 and 73 characters while the byte length stays at 75 every time.
The second catch is that folding happens at a byte boundary, not a word boundary, so the file splits words in half:
DESCRIPTION:Meeting\nLength: 1 h\n\nLondon: 2026-11-07 15:00–16:00 GMT (U
TC)\nNew York: 2026-11-07 10:00–11:00 GMT-5 (UTC-5)\nChatham: 2026-11-08
04:45–05:45 GMT+13:45 (UTC+13:45) (+1 day) – outside working hours\nT
okyo: 2026-11-08 00:00–01:00 GMT+9 (UTC+9) (+1 day) – outside working
hours\nSydney: 2026-11-08 02:00–03:00 GMT+11 (UTC+11) (+1 day) – outsi
de working hours\nAuckland: 2026-11-08 04:00–05:00 GMT+13 (UTC+13) (+1 d
ay) – outside working hours\nAdelaide: 2026-11-08 01:30–02:30 GMT+10:3
0 (UTC+10:30) (+1 day) – outside working hours\n\nUTC: 2026-11-07 15:00
UTC to 2026-11-07 16:00 UTC
"GMT (U" then "TC)", "outsi" then "de working hours", "Chatham: 2026-11-08" then "04:45–05:45" on the next line. Each continuation starts with a single space, which is the standard unfold marker, so a conforming client puts the text back together - but a script that reads the file line by line gets fragments.
The DESCRIPTION itself carries one line per place, in the plan's order, with the local times, the offset in both forms, the day marker and the working-hours flag: "– outside working hours" on the four places that were outside their window. It closes with the UTC range spelled out, "UTC: 2026-11-07 15:00 UTC to 2026-11-07 16:00 UTC".
What the guide says
The live guide says you can "Search the browser's time zone list by city or zone name and see each place's UTC offset and abbreviation for the chosen date." Its limits section says "Plans hold two to eight places, dates from 1970 to 2100 and meetings from 5 minutes to 24 hours." and "There are no recurring events, attendees, reminders or holiday data." and "Offsets rely on your browser's time zone database, so an out-of-date browser may disagree with very recent rule changes."
Its own question about this case is answered in the affirmative: "Can it handle half-hour zones and clock changes? Yes. Offsets such as UTC+5:45 and 30-minute daylight saving changes are shown, and the date you choose decides which offset applies." And it closes with "Time Zone Planner runs in your browser with no account or payment details, and it never uses OnePassApps credits."
I reproduced the half-hour and 45-minute part of that. I did not reproduce the 5:45 example: in my session the searches for "Kolkata" and "Asia/Kolkata" produced no row to add, so I could not put a 5:45 zone on the board. The two I did put there were +10:30 and +13:45.
What I did not measure
- I did not change the date away from 7 November 2026, so nothing here is claimed about a daylight-saving transition or the 30-minute daylight saving change the guide mentions.
- I did not press "Copy summary", and I did not open the in-app "How to use Time Zone Planner" panel, so nothing from either is quoted here.
- I did not run a network trace, so "Nothing leaves this tab." is the app's own wording, not something I re-measured.
- The two searches that returned nothing usable were "Kolkata" and "Asia/Kolkata"; I do not know why, and I did not try other spellings.
- One browser, one signed-out session, one build, 7 November 2026. The offsets come from this browser's own time zone database, which is what the guide says it uses.
I work on OnePassApps, so this is our own build and our own data - the numbers above are what the panel printed and the bytes above are what the file contained.
Top comments (0)