Skip to main content
All updates
ImprovementScheduleClasses·Fri Sep 04·

Atomic recurring schedules and venue wall time

The primary web schedule editor now uses the same canonical series core as the admin API. A create or edit is one database transaction covering its template, rolling occurrence projection or recurrence reconciliation, booked/conflict confirmation, audit evidence, and durable notification obligation. A failed audit or any other database step rolls the whole mutation back; notification delivery can

The primary web schedule editor now uses the same canonical series core as the
admin API. A create or edit is one database transaction covering its template,
rolling occurrence projection or recurrence reconciliation, booked/conflict
confirmation, audit evidence, and durable notification obligation. A failed
audit or any other database step rolls the whole mutation back; notification
delivery can retry from the outbox without replaying schedule writes.

Occurrence instants are built from the occurrence's calendar date plus wall
time in the venue's IANA timezone. Copenhagen summer and winter dates therefore
retain the operator's intended local time with the correct UTC offset. A spring
DST gap is rejected before save. An autumn repeated time exposes explicit
Earlier and Later choices (including offsets), and the selected policy is saved
on the template for later generator runs. The database independently
round-trips every supplied instant through the venue timezone before accepting
it.

Structural edits reconcile the rolling 30-day window: missing desired
occurrences are created, stale unbooked occurrences are cancelled, and a stale
booked occurrence is never silently removed. `from_date` begins at that
venue's local midnight. A structural rewrite over historical occurrences is
intentionally unavailable; operators must correct those classes individually.

Client parity classification:

- **Business Mobile:** the shared REST contract accepts the new recurrence,
  streaming, scope, and `ambiguous_time_choice` fields and returns the same
  refusal codes. A native Earlier/Later picker is still a bounded client UI
  follow-up before Business Mobile can author a repeated wall time directly.
- **Consumer and Branded apps:** no schedule-authoring UI change. They consume
  the corrected occurrence instants through existing schedule reads.
- **Shared-data impact:** yes. All clients see the transactionally reconciled
  class instances; no public response field was removed or renamed.

No new public help or marketing material is required. This is reliability and
operator-safety hardening of an existing capability.
Next update

Flexible pass publishing works again

Valid Flexible pass drafts can now be published normally; failed attempts kept the saved draft and created no partial pass.