Planning method

Opening windows: checking whether a visit actually fits

An opening-hours label is not the same thing as a workable visit. “Open until 17:00” leaves unanswered questions: Is the selected sub-service running? Is last entry earlier? Does the visitor have enough time to complete the visit? Does a dated exception replace the regular schedule? Is the source current and publishable?

Asmaliana treats a visit window as an evidence-backed interval calculation, not a promise that a door will be open in real time.

This guide explains the method. It contains no claim about a real venue.

The five times in a window check

A useful check separates at least five concepts:

1. Arrival time — an exact instant supplied by the caller, with an offset or interpreted under the documented local-time contract.
2. Scheduled opening — the start of an applicable published interval.
3. Last entry — the latest admitted arrival according to the available rule; it may be earlier than closing.
4. Required departure — arrival plus the requested or evidenced minimum visit duration.
5. Scheduled closing — the end of the applicable interval.

A visit generally fits a published interval only when arrival is allowed and the required departure does not exceed the interval’s usable end. The service still needs to report evidence gaps and real-time limitations.

A small synthetic example

Suppose a fictional demo gallery has a reviewed demo interval from 10:00 to 13:00, last entry at 12:15, and a minimum useful duration of 60 minutes.

• Arrival 11:30 for 60 minutes fits the published interval.
• Arrival 12:10 passes the last-entry test but would end at 13:10, so it does not fit the duration requirement.
• Arrival 12:20 fails the last-entry rule even if the visitor asks for only 20 minutes.
• Arrival 09:55 does not fit unless the contract explicitly supports waiting and represents that assumption.

The conclusion describes the published rules only. It does not confirm current operations, capacity, admission, or a booking.

Multiple intervals are not one long interval

A place can have two intervals on the same local date. A gap between them is closed time, not a continuous opening window.

For example, synthetic intervals 09:00–12:00 and 14:00–18:00 do not accommodate a visit from 11:30 to 14:30. The visit overlaps both intervals but is not wholly contained in either. Splitting a visit would be a different plan and must be explicit.

This is why storing only a daily opening and closing time loses important meaning.

Date exceptions take precedence

Recurring weekday rules answer the ordinary case. A dated exception can replace them with:

• a closure;
• one or more changed intervals;
• an explicitly unknown/conflicting state.

The applicable dated exception wins over the recurring rule. If the service has no reviewed holiday rule, it should not guess from the name of a holiday or from another year’s behavior. The result should identify that uncertainty.

Cross-midnight intervals

An interval such as 20:00–01:00 crosses a local date boundary. It cannot be represented safely by sorting the two clock values and assuming the smaller one is the start.

The schedule rule needs an owning local date plus an end on the following date. A check at 00:30 may belong to the previous date’s interval. Even though the P0 day planner is limited to one local date, the schedule engine still has to model the interval correctly so a late visit is not rejected or assigned to the wrong day.

Place status and service status are separate

A building may be scheduled open while a particular tour, exhibition, kitchen, lift, or other service is paused. A caller selecting that service needs a conflict or verification requirement even when the parent place is open.

Keep these concepts separate:

• scheduled_open: what the published schedule says;
• operating_status: a reported operational condition;
• product_status: whether the selected service/product is offered;
• availability: whether capacity is known;
• booking_confirmation: whether a reservation exists.

A positive value in the first field does not imply positive values in the others.

Evidence can change the assessment

The calculation also inspects evidence state:

• A reviewed, applicable interval can support the schedule dimension.
• A stale interval may still be displayed but should produce a freshness warning or verification requirement under policy.
• Conflicting intervals cannot be resolved by whichever was imported last.
• A restricted value may be known internally but unavailable for display or API redistribution.
• A pending-review interval is not silently treated as published truth.

Therefore, two visits with identical clock arithmetic can have different assessments because the evidence supporting the schedule differs.

Reading the result

A good result answers these questions directly:

• Which place and optional service were checked?
• Which local date and timezone were used?
• Which schedule interval and exception applied?
• Did arrival pass last entry?
• Did the requested duration fit?
• What does the evidence say, and when was it checked?
• Which dimensions were not checked—live operations, capacity, ticket inventory, or booking?
• Is the assessment feasible, infeasible, or needs_verification?

success=true in an API envelope means the calculation ran. It does not mean the visit is confirmed.

Why “needs verification” is useful

Unknown is not a software failure. If the only published rule is stale, if an exception is unresolved, or if a service status is missing, needs_verification prevents a weak assumption from becoming an apparently precise plan.

The next action should be narrow and authorised: for example, inspect a cited current source. P0 does not contact a venue or claim it has obtained confirmation.

A practical checklist

Before accepting an opening-window result, check:

• Correct stable place and service IDs.
• Arrival includes the intended offset/local date.
• Requested duration is realistic and its source/assumption is visible.
• One applicable interval fully contains the visit.
• Last-entry and dated exceptions were evaluated.
• Cross-midnight logic uses the correct owning date.
• Place and selected service states are both considered.
• Evidence is reviewed, applicable, and not silently conflicting.
• Live operation, capacity, and booking remain explicitly outside scope unless separately evidenced.

That checklist is the difference between displaying hours and testing a visit that can be reasoned about.