Who actually needs this

A touring show playing six cities across two countries. An online course with sessions scheduled in the tutor's timezone while students are elsewhere. An agency running one WordPress install for venues in several regions. A conference with satellite events abroad.

If everything you do happens at one address, you do not need per-event timezones and you should not go looking for them. The site setting is enough and it is simpler.

The workarounds, and why they fail

Writing the offset into the title. “Doors 8pm (EST)” is at least honest, but it is wrong for half the year — the venue is on EDT in summer — and it cannot be sorted, filtered or exported. It also does not survive into anyone's calendar app.

Converting everything to the site's zone by hand. Now the stored time is not the time anybody experiences, and every person entering an event has to do arithmetic correctly, including across the fortnights when the two countries' clock changes are out of step. It will go wrong.

A separate WordPress site per region. Solves the timezone problem and creates a much larger content problem. Occasionally right for an agency; almost never right for one organisation.

How it should work

Each event carries a wall-clock time plus the name of its zone, and the site's setting becomes a default rather than a law. The Manchester show is 20:00 in Europe/London; the New York show is 20:00 in America/New_York. Both are stored as what they are.

The comparable UTC instant is derived for sorting and filtering, so a list of upcoming events across six cities orders correctly. But the derived value is never the source of truth — because if it were, a change to a country's daylight-saving law would silently shift the stored event.

What to show the visitor

For a physical venue: the local time at the venue, with the zone labelled. Somebody buying a ticket for the New York show needs to know it starts at 8pm in New York, not what that is where they are sitting.

For an online event: the visitor's own time is genuinely more useful, but say so — “19:00 CET (13:00 your time)” rather than silently converting, which leaves people unsure which they are looking at.

The export test

Whatever you use, publish the calendar as an .ics feed and subscribe to it from Google Calendar. If a New York event and a London event both appear at the right local times in a subscriber's app, the model underneath is sound. If they do not, no amount of display logic will save it — another calendar reading your feed is the harshest and most useful test there is.