Offerings & schedules

An offering is a bookable service — typically your dinner service. The offering decides who approves a booking (instantly, or by the venue), how large a party may be and how far ahead guests may book; the weekly schedule decides when slots exist and how long they are. Both are configured per venue by a manager or above (venues.manage); every staff role can read them. Editing happens in the “Local schedules and exceptions (DEV-014 panel)” at /app/panels.

Offerings

Form “Save an offering”:

Field	What it is	Rules/limits
Offering id	Identifies an existing offering to update.	Leave blank to create.
Name	The service name guests choose (“Dinner”).	1–100 characters, unique within the venue.
Approval mode	INSTANT or REQUEST.	INSTANT books confirm on the spot. REQUEST creates a pending request the venue approves or declines (manager and up decide); an undecided request expires at the earlier of its 24-hour review deadline and the service start.
Minimum party	Smallest party accepted.	1–200, default 1.
Maximum party	Largest party accepted.	1–200, default 8, and at least the minimum.
Default duration minutes	How long a table is planned for.	15–480 minutes, default 90.
Notice minutes	Online lead time.	0–10080, default 60. Slots inside the lead time are shown to guests as not selectable (“too soon — call us”); staff taking a phone or walk-in booking are exempt because the venue itself is taking the booking.
Horizon days	How far ahead guests may book.	1–365 days, default 90. Beyond it: “Beyond the booking horizon — no slots offered.”
Active	Whether the offering participates.	Inactive offerings keep history but cannot be booked.

OFFERING_NAME_TAKEN (409) — another offering of this venue already uses that name.

Deposit charging is a per-policy setting, not an offering setting; it exists but stays switched off in this pilot — see Booking policies & cancellation.

Weekly service windows

Weekly windows are published as one complete set per offering (form “Publish the complete weekly set”): rows that keep their stable schedule id are updated in place, rows without one are created, and rows absent from the set are removed. An offering carries 1–20 window rows, and labels must be distinct within the offering.

Row field	What it is	Rules/limits
label	Window name (“Dinner late”).	1–80 characters, distinct within the offering.
weekday	Day of week.	0 = Sunday through 6 = Saturday.
startsLocal / endsLocal	Wall-clock start and end.	24-hour HH:mm in the venue’s own time.
endDayOffset	Overnight marker.	0 for a same-day window (which must end after it starts), 1 when the window wraps past midnight.
slotMinutes	Bookable slot length.	5–60 minutes, in 5-minute steps.
preBufferMinutes / postBufferMinutes	Turnaround time reserved before/after each seating.	0–240 minutes each; slots are trimmed so a party’s buffer-inclusive interval fits inside the window.
maxArrivalsPerSlot	Soft pacing cap on arrivals per slot.	1–500, optional.
maxCoversPerSlot	Soft pacing cap on covers per slot.	1–2000, optional.
hardConcurrentCovers	Hard ceiling on concurrent covers.	1–5000, optional; can never be overridden.
durationBands	Optional per-party-size duration overrides.	1–10 bands, each 15–480 minutes.
Active	Whether the window participates.	Inactive windows stop producing slots.

Overlapping weekly windows are refused with RULE_VIOLATION (422): “These weekly windows overlap — adjust the days or times.”

Publishing bumps the venue’s service revision (see below).

Business date, time zones and UTC

Three different time notions are kept deliberately separate:

• Business date — the venue-local calendar date (YYYY-MM-DD) the service starts. A Friday window running 22:00–02:00 with an overnight offset belongs to Friday’s business date even though part of it falls on Saturday.
• Venue time zone — one IANA zone per venue, set at creation; all wall-clock configuration is interpreted in it.
• UTC instants — only actual bookings store UTC instants. A slot is a wall time until someone books it; then it becomes an exact instant.

Daylight-saving handling

Slot generation resolves daylight-saving changes explicitly:

• Spring forward (a wall time that never exists): the slot is never offered — generation records it as a skipped gap slot, and a pick-a-time lookup answers: “{wall} does not exist on this date in {timezone} (the clock jumps forward). Pick another time.”
• Fall back (a wall time that happens twice): both occurrences are offered as two distinct bookable instants, each with its own UTC offset, and the ambiguity is disclosed rather than hidden: “The clock repeats: {wall} happens twice on this date in {timezone}. Choose the first or second occurrence.”

Guests always deal in venue-local times — the slot chips and the confirmation line show the venue’s clock and zone — and a repeated hour is resolved by an explicit first-or-second choice, never guessed.

Service exceptions (one-off dates)

Form “Save a date exception” handles holidays, private events and one-off hours for a single business date:

Field	What it is	Rules/limits
Schedule id	Which weekly window the exception targets.	Blank = a venue-wide closure (closures only — an override always needs a specific schedule).
Business date	The affected date.	YYYY-MM-DD, a real calendar date.
Mode	CLOSED or OVERRIDE.	CLOSED shuts the venue or that window for the day; OVERRIDE replaces the weekly window with the given one.
Override window	Replacement start/end and slot length.	HH:mm times with the same overnight offset rule; slot length 5–60 minutes.
Reason	Why the exception exists.	1–300 characters, required — it is recorded for audit.

EXCEPTION_DATE_TAKEN (409) — that date already carries an exception for that scope. Edit the existing exception instead of adding a second.

Saving an exception also bumps the service revision.

The service revision and AVAILABILITY_STALE

Every publish and every exception save increments a counter on the venue called the service revision. Each availability read reports the revision it was computed from, and every booking write must present the revision it read. If the schedule changed in between, the write refuses with AVAILABILITY_STALE (409): “The service changed since the read — refresh the availability first.” The remedy is always the same: re-read availability for that day and book from the fresh picture. This is how DineGlobe makes sure no booking is ever committed against a stale view of the floor.

For what guests experience when booking these slots, see Making a booking; for same-day intake see Walk-ins & staff intake.