GratisAI travel · compare calendar-day and rolling-hour expiry for a city pass · local-first FREE TIER 1 Free Run Available
validity-window stub · punched ticket stubs

Compare Calendar-Day and Rolling-Hour Expiry for a City Pass

A two-day pass may mean two calendar dates or forty-eight rolling hours. Model both stated conventions beside a proposed visit so the activation time cannot hide a different expiry boundary.

1 · visit label | activation local YYYY-MM-DDTHH:MM | visit local YYYY-MM-DDTHH:MM

FIRST-LOAD

HYPOTHESIS / PROTOTYPE — checkout unavailable. Calculation is local. A draft is saved automatically in this browser profile when storage is available; Reset to sample clears it. Optional Pro history stores only five summaries and has its own deletion control. State links encode your inputs and can remain in browser history, clipboard or recipients’ records; share only non-sensitive rows. Optional external AI formatting leaves this device. The required site analytics beacon reports page activity; shared URLs contain encoded inputs. Do not treat an encoded URL as private. The calculator has no input-collection endpoint.

Data note: The validity-window stub processes visit label | activation local YYYY-MM-DDTHH:MM | visit local YYYY-MM-DDTHH:MM locally. Starter/sample selection and Run compute in this tab; no input is sent by the calculator. A local draft may be saved; explicit state-link sharing or optional external AI formatting can disclose inputs. Use non-sensitive labels.

Perspective: Before: the phrase two days hid the activation convention. After: rolling and calendar expiry boundaries are visible as two hypothetical models, not entry permission.

2 · Read the validity-window stub

Hypothetical validity-window arithmetic only, not an entry guarantee, verified pass policy or consumer-rights advice. Both models assume a constant local offset and exclusive expiry; no opening hours, reservations or exclusions are checked. Confirm actual activation and expiry terms with the pass provider before purchasing or planning a visit.

Optional filing controls are a local prototype.

Checkout is unavailable. The reading above is complete; print, CSV and five local summaries are optional enhancements, not hidden answers.

Before using the validity-window stub

Treat the two columns as questions for a provider, not a choice the traveler can make after purchase. An actual pass has one published rule, possibly with special attraction or booking restrictions. This instrument deliberately labels both hypothetical models. The calendar model counts the activation date as day one and ends at midnight after the last included date. The rolling model adds twenty-four clock-hours for every purchased day. Both assume one fixed local offset, which is appropriate only when no relevant clock change occurs. If the journey crosses a seasonal clock change, use the provider’s explicit expiry instant instead of this simplified comparison. A visit row can show disagreement even when no attraction is open at that time; opening hours are not checked.

Boundary and sources

Hypothetical validity-window arithmetic only, not an entry guarantee, verified pass policy or consumer-rights advice. Both models assume a constant local offset and exclusive expiry; no opening hours, reservations or exclusions are checked. Confirm actual activation and expiry terms with the pass provider before purchasing or planning a visit.

Mechanism: competence-autonomy-loop

Optional AI formatting, never the calculation

Manual entry completes this validity-window stub for free without signup. If available to you, the free AI Studio interface linked in the sources may format fictional or non-sensitive notes; external access may require an account. No API key or AI call is built into this tool. Free-tier content may be used to improve products. Review each cell and transcribe it to the labeled row schema; do not paste the JSON object into the row box.

Format only these fictional or non-sensitive notes for a validity-window stub. Return strict JSON shaped as {"rows": [{"label": "string", "cells": ["string", "string"]}], "setting": "string"}. The columns are visit label | activation local YYYY-MM-DDTHH:MM | visit local YYYY-MM-DDTHH:MM; the setting is Purchased duration in whole days. Keep all supplied strings and quantities exactly; do not calculate, infer missing entries, invent dates or add advice. If any required value is missing, return an empty rows array and ask me for it separately. I will verify every cell against my source and manually transcribe rows using vertical bars before running the local calculator.

An AI response is not executed, fetched or trusted as a result. Missing values remain questions; the strict local parser checks the rows you actually enter.