Timezones & venue time

A restaurant runs on its own clock. Next Restaurant shows every time in the venue's timezone — never the timezone of the device looking at it. A 19:30 booking reads 19:30 to the host on the floor, to the owner checking in from abroad, and in the confirmation email.

Where the clock comes from

Each venue's clock is resolved in this order, most specific first:

The location's timezone — set on the location.
The restaurant default — Settings → Date → Timezone.
Joomla's timezone — System → Global Configuration → Server → Website Time Zone.
UTC.

Leave a field blank to fall through to the next one. A single-venue site usually sets just the restaurant default (or nothing, if Joomla's timezone is already right); a group with venues in different zones sets each location.

Setting it

Locations → (a location) → Timezone. The first option, Use the restaurant default, shows which zone that currently means.
Settings → Date → Timezone. The first option, Use the site's Joomla timezone, falls back to Joomla.

Both pickers list every timezone with today's offset from UTC, daylight saving included. Pick a city (America/Chicago), not a fixed offset: cities follow daylight saving, offsets don't. A name that isn't a real timezone is refused on save.

What follows the venue's clock

Every screen that shows a time — orders, payments, bookings, shifts, the kitchen display, the floor map, receipts, the payments export and emails.
"Today" — the dashboard, the booking list's default day, and the earliest date a guest can pick on the booking form are the venue's today, even when the viewer's device is already on tomorrow.
Days in reports. Sales, payment breakdowns, item and channel reports, and staff hours are counted on venue days, from venue midnight to venue midnight. An order at 19:00 lands on that evening's day, not on the next UTC day.
Timesheets. A shift is filed under the day it happened at the venue, so hours — and payroll — add up per real working day.
"All locations". When a report or list spans venues in different zones, each record is held to its own venue's day.
Coupon and gift card dates are on the restaurant's calendar (the restaurant default zone).

Daylight saving is handled: a report for the day the clocks change covers 23 or 25 hours, exactly as the day really was.

What is stored

Times are stored in UTC and converted for display, so nothing in the database depends on the server's own clock or location.

For integrations, this means timestamps returned by the REST API — such as an order's placed_at — are UTC. Each location in the API carries its timezone, the zone the venue actually runs on, for converting them.

Changing a timezone later

Set the timezone before you start taking bookings and orders.

Changing it afterwards changes how existing records are displayed, not the moments they refer to. Orders and shifts are real moments, so they are simply shown on the new clock. A booking, though, was made for a time on the old clock: if a venue ran on the wrong zone when a booking was taken, that booking moves when the zone is corrected, and needs checking.