← All help articles

Time zones in 1pm

eventsrun-of-showtroubleshooting
Time zones in 1pm

Times in 1pm are simpler than they look. There is no time-zone picker on the event, no drop-down to convert between cities, no setting on your profile. Every time you type is the literal time at the venue, and every crew member sees that same literal time, regardless of where in the world they open the link from.

This article explains why we did it that way, what that means in practice, and the handful of edge cases worth knowing about.

The one rule

Every time stored in 1pm is the wall-clock time at the venue. The 18:30 you type for "Doors open" is the time someone standing at the venue would read on their watch. That is the time the crew see. That is the time the printed run sheet shows. That is the time on the live shareable link.

There is no conversion happening anywhere. 1pm does not try to be clever about turning your local time into the crew's local time. It deliberately keeps things flat. The venue's clock is the source of truth, and everyone reads from that clock.

Why we don't translate times

Run-of-show software that converts times for each viewer sounds helpful on paper. In practice it causes more confusion than it prevents. A few of the scenarios where time conversion goes wrong:

Say you're at home in Sydney editing an event happening in Auckland. With auto-conversion, "ceremony at 4pm" would mean 4pm Sydney time on your screen but 6pm at the venue. You picture the ceremony, type the time you pictured, and the system silently shifts it two hours. Confusing.

The DJ flies in the night before from Melbourne. With auto-conversion, the DJ's phone shows the run sheet in Melbourne time. They walk into the Sydney venue having seen "10pm last dance" and discover everyone is calling last dance at "10pm Sydney time", which by their phone's clock was an hour ago. Confusing.

Industry convention is the same conclusion. Every BEO, every printed run sheet, every venue's daily diary uses the venue's local time, without qualification. 1pm matches that.

What about "now"

A few places in 1pm show "now": countdowns, "happening now" badges, "started 12 minutes ago" labels. These all read from the device's local clock. There is no concept of a venue time zone stored on the event, and the page does not try to compute one.

The home dashboard shows "Today" and "Next 7 days" tiles. These are calculated against your computer's clock when you load the page.

The crew view shows countdowns and "happening now" indicators against the device the crew member is reading on, also from that device's local clock.

The reason this works in practice: when an event is actually happening, the crew member reading the page is almost always at the venue, so the device's local time and the venue's wall-clock time are the same. The stored times (e.g. "18:30") are parsed by the browser as 18:30 in whatever zone the device is currently in, and "now" is compared against that. If the crew is at the venue, the comparison is correct.

A time looks wrong on the page

Almost always one of these:

  • You typed a time in 24-hour format and meant 12-hour, or vice versa. 18:30 and 6:30 look very different on the page. Click the cell, retype.
  • You typed the right time but in the wrong field. The Start time and the End/Duration are separate. If your event starts at 9am and ends at 5pm, both fields need to reflect that.
  • A crew member is looking at a stale page that hasn't refreshed. Ask them to pull-to-refresh once. The page picks up the corrected time.

If a stored time is genuinely wrong in the planner (not just rendered wrong), edit the cell and retype. The change propagates to the crew view within a second.

Daylight saving in short

If the venue is in a region that observes daylight saving, the stored times are the times on the local clock at the moment the event happens. 1pm does not need to know whether DST is in effect or not: you typed 9am, the venue's clock will read 9am at the moment the event runs, and that's the only thing that matters. The system stays out of the way.

If you re-use a template across a DST transition (for example, the same wedding template in March before the clocks change and in October after they change), the stored times in the template are just numbers (9am, 3pm, etc.). When you stamp the template into a fresh event, those numbers become the wall-clock times on that event's date. The template doesn't carry a time zone with it because there isn't one to carry.