Seasons and schedules

A season is a name and a date range. Nothing else. "Summer 2026-2027, 1 November to 30 March" — that is the whole thing.

It belongs to your dive center, so you write it once and every service points at it. The schedule that says what a service costs and when it goes out during that season is a separate thing, and it is the piece that actually fills your calendar.

Creating a season

Offerings › Seasons › + New Season: a name and two dates.

Each one shows a status — upcoming, running or finished — worked out from your center's local date. It is informational: it does not enable or block anything.

Seasons are allowed to overlap

The editor warns you when two seasons share dates, but it does not stop you. Overlapping is unusual and perfectly legitimate: an "Easter week" sitting inside "Low season" with different prices is exactly that.

Linking a service to a season

The link carries what the season does not: the price for that period, the days of the week, the departure times and the capacity of each one.

You can build it from either side, and it is the same panel:

• From the season — open it and you get a screen listing the services, with a switch on each. Flipping the switch links it straight away; the panel then opens so you can load the days. Linking three services should not cost three forms.
• From the service — open it and pick which season this schedule is for.

A brand-new link has no days yet, so it produces nothing on the calendar until you give it some.

Always — no season

A service that runs all year does not need a season covering the whole calendar. Pick Always — no season in the picker and its schedule simply repeats inside the rolling 12-month horizon.

It is an explicit option rather than leaving the field blank, because an empty field does not tell "runs all year" apart from "I have not chosen yet".

The one rule that is enforced

Two schedules of the same service cannot cover overlapping dates. A given Monday 09:00 would come out of both rules and there would be no answer for which price applies, so the portal rejects it.

Note the difference from the tip above: two seasons may overlap; two schedules of one service may not.

Editing a season that has already started

You can. There is no lock, on purpose — the case that decides it is real: your summer runs November to March, and in December you want to fix February's price. A lock would push you into creating "Summer 2026-2027 (bis)", fragmenting exactly what seasons came to unify.

What protects you instead is the report. Saving or deleting a season rebuilds the center's calendar and tells you what happened: how many departures were created, updated and deleted — and how many were left detached.

Detached departures need a decision

A departure that already has divers booked is never deleted silently because the schedule moved out from under it. It is left detached and flagged, and you decide whether to keep it, move it or cancel it.

Closing days is somewhere else

There is no "excluded dates" field here. The single place to close a day — a holiday, a maintenance day, bad weather — is Settings › Closed days, and it closes the day for every service at once. Two places to do the same thing confused more than they helped.

Capacity matters

A departure with no capacity accepts divers without limit, and then occupancy and "seats booked" cannot mean anything. Set a capacity on every departure time.