Finding a time that suits six people is a solved problem with several tools, most of which want an account. A link-based version is genuinely useful and the time zone handling teaches you something.

1. No accounts, ever

Create a poll, get a link, send it. Anyone with the link adds their name and availability. That's the whole flow, and removing the signup is most of why people would use yours.

The poll's identity is a long random ID in the URL. Unguessable, and that's your access control.

availability-poll.txt
Build an availability poll. Stack: <stack>.

- Create a poll with a title and a set of candidate dates or time
  slots. Returns an unguessable link.
- Participants add a name and mark each slot yes / no / maybe. No
  account.
- A grid showing everyone's answers and the best slots.
- Participants can edit their own response — using something stored
  in their browser, not an account.

Time zones: store every slot as an absolute instant. Display in each
viewer's local zone, and label it clearly. A participant in another
country must see their own times.

2. Time zones are the whole difficulty

The organiser picks "Tuesday 3pm". A participant in another country must see their local equivalent, correctly, including across a daylight saving boundary.

Store absolute instants. Never store "3pm" and a date separately. And always show the zone alongside the time, because a bare time is ambiguous to everyone who isn't in your zone.

3. Show the answer, not just the data

The grid is the input. The output is "Tuesday 3pm works for 5 of 6, Sam can't make it". Compute and show the best options prominently — that's the thing the organiser opened the page for.

4. Practical details

Let people mark "maybe", which is how availability actually works. Show who hasn't responded. Give the organiser a way to close the poll and announce the result.

Store the participant's own edit token in local storage. It lets them come back and change their answer without an account, and without letting them edit anyone else's.