I work on OnePassApps, and this one is our own app: the Time Zone Planner, the route we serve at app.onepassapps.com/apps/time-zone-planner. I ran it in the live tab on 6 November 2026, and everything below is what the panel actually showed.
The default plan
Two places load with the app: London and New York, both with a 09:00–17:00 working day, today's date, and a one-hour meeting at 15:00 in the reference place. The plan header reads "2 places · 1 h meeting". The overlap line reads "Shared working hours: 14:00–17:00 London".
That number is arithmetic I can check by hand. London was on GMT (UTC+0) that day and New York on GMT-5 (UTC-5), so New York's 09:00 is 14:00 in London, and New York's 17:00 is 22:00 in London. London works 09:00–17:00 and New York works 14:00–22:00 in London terms, so the overlap is 14:00–17:00. The app agrees.
The labels move when the date moves
Set the date to 15 July 2026 and the same two places re-label themselves: "Europe/London · BST · UTC+1" and "America/New_York · GMT-4 · UTC-4". The wall-clock plan does not move at all: the overlap is still "Shared working hours: 14:00–17:00 London", the 15:00 meeting is still 15:00 in London and 10:00 in New York, and only the dates in the table change to 2026-07-15. Both sides shift their offset by an hour, so on those two measured dates the gap between them stays five hours and every local time stays put.
A meeting is checked at both ends
Change New York's day to end at 12:00 and move the meeting to 16:30. The table then shows "Outside working hours" for both places: London 16:30–17:30 runs past London's 17:00 end, and New York 11:30–12:30 runs past its 12:00 end. The panel states the rule in its own words: "Hours are checked at both ends of the meeting." A half-hour meeting at 16:30 would fit in both windows; the one-hour meeting does not.
Overnight working windows
Give New York a 22:00–06:00 window and the overlap line becomes "Shared working hours: 09:00–11:00 London". With New York on GMT-5 and London on GMT that day, a 22:00 start in New York is 03:00 in London and a 06:00 end is 11:00 in London, so the two windows share two hours at the start of London's working day.
The calendar file
Press "Download .ics" and the browser writes meeting-2026-11-06.ics: 544 bytes, produced in the tab. The blob the button creates is text/calendar and also 544 bytes, the same size as the file that lands on disk. The header lines are the standard ones — VERSION:2.0, CALSCALE:GREGORIAN, METHOD:PUBLISH, and PRODID:-//OnePassApps//Time Zone Planner//EN — then one VEVENT with a UID and a DTSTAMP. The file is a plain RFC 5545 calendar, trimmed here to the header and the event:
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//OnePassApps//Time Zone Planner//EN
CALSCALE:GREGORIAN
METHOD:PUBLISH
BEGIN:VEVENT
UID:af0103e1-2b29-4d51-af58-465998bdb928@onepassapps
DTSTAMP:20261106T034758Z
DTSTART:20261106T163000Z
DTEND:20261106T173000Z
SUMMARY:Meeting
DESCRIPTION:...
END:VEVENT
END:VCALENDAR
The DESCRIPTION lines follow, folded across the file as the spec requires.
Two details matter before you import it:
- The times are UTC instants, not local times with a zone attached: DTSTART:20261106T163000Z and DTEND:20261106T173000Z. London was on UTC+0 that day, so 16:30 in London is 16:30Z.
- There is no VTIMEZONE block anywhere in the 544 bytes. The file carries one absolute instant per event rather than a recurring local rule, so a meeting that repeats has to be created again for each date.
The DESCRIPTION carries the same plan as plain text — the length, then a line per place: "London: 2026-11-06 16:30–17:30 GMT (UTC) – outside working hours" and "New York: 2026-11-06 11:30–12:30 GMT-5 (UTC-5) – outside working hours" — and it closes with a UTC line. Leave the title field empty and the SUMMARY is the plain word "Meeting".
What it does not do
The page is plain about the limits: two to eight places, dates from 1970 to 2100, meetings from 5 minutes to 24 hours, one daily working window per place, and no recurring events, attendees, reminders or holiday data. It says the offsets come from your browser's own time zone database, so an out-of-date browser may disagree with very recent rule changes.
It also says "Your plan stays in this tab and needs no account" and "Nothing leaves this tab." Those are the app's own claims. I did not run a full network trace this time to test them, so treat them as what the app says rather than as something I measured.
The search box filters as you type: typing "Tokyo" narrows the list to a Tokyo · Asia/Tokyo entry. Every place carries its own start and end time, one button per place makes it the reference, and the Reset button's accessible label is "Reset example".
Try it
Open the Time Zone Planner in your browser, 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.
I work on OnePassApps, so every number above comes from our own build on 6 November 2026 — one browser, one date, one session, signed out.
Top comments (0)