Time zones in 1pm — Help

Times in 1pm are simpler than they look. There is no time-zone picker on the event and no drop-down to convert between cities. 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.

There is exactly one time-zone setting on your account, and it does not touch any of that. It tells 1pm which day "today" is, and which offset to publish your calendar feed at. It is covered below.

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.

The one setting there is

Your account has a single time zone, and it is easy to miss because of where it lives: Account, then Calendar sync. It was put there because publishing the calendar feed is what first needed it, but it is not only a calendar setting any more.

Pick the zone your venue is actually in. The list is grouped by region and each option leads with the city, so typing the first few letters of the city jumps to it. There is a link that fills in whatever zone your browser reports, which is right most of the time and worth a glance before you accept it.

What it governs:

The calendar feed. A subscribed feed carrying no zone makes Google lock the whole calendar to UTC, and every timed booking shows shifted. This setting is what anchors those times correctly. See Sync your bookings to Google, Outlook, or Apple Calendar.
What counts as "today". The Today and Tomorrow labels on your events list, and the date ranges your money reports run over. The server runs on UTC, so without this an account in Brisbane or Los Angeles sees events on the morning of the day filed under the wrong one.
Appointment reminders and confirmation emails, which need a real date to write into the message.

What it does not govern: the times you type on an event. Those stay literal venue times, exactly as described above. Changing this setting will not shift a single run-of-show item, and it is not a way to move an event between cities.

Leaving it unset is allowed, and the option says so: No zone set (floating times). 1pm then falls back to the zone your browser reports, and finally to UTC. That works, but it is guesswork, and it is the usual cause of a calendar feed that reads an hour or two out. Setting it takes a moment and removes the guess.

Changing it later republishes the feed at the new offset. Google in particular can sit on a cached copy for a long time afterwards, which is its own problem with its own fix: see Google Calendar is showing old times.

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.

Date labels like "Today" and "Tomorrow" on the events list are the exception, and they are worth understanding. They are worked out against your account's time zone, which is the setting described above, not the server's clock and not your browser's. 1pm resolves your stored account zone first, falls back to the zone your browser reports, and only then to UTC.

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.

Sync your bookings to Google, Outlook, or Apple Calendar covers the feed, and the page your account time zone is set on.
Google Calendar is showing old times covers the cache that keeps drawing the old offset after you change the setting.
Importing bookings from a calendar covers the conversion that happens on the way in, which is the one place 1pm does shift a time.
Appointments and the booking page covers the reminders that read this setting.