Compare Calendar-Day and Rolling-Hour Expiry for a City Pass — Free
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.
The proof surface
Pass break-even tools compare fares. This stub compares time conventions instead: activation day counts in the calendar model, expiry is exclusive in both, and no provider rule or entry entitlement is inferred.
Inputvisit label | activation local YYYY-MM-DDTHH:MM | visit local YYYY-MM-DDTHH:MM; purchased duration in whole days
Rare devicePass break-even tools compare fares. This stub compares time conventions instead: activation day counts in the calendar model, expiry is exclusive in both, and no provider rule or entry entitlement is inferred.
Output artifactVisits where modeled rules disagree with row-by-row context
Cost$0 local calculation · no card, paid key, subscription or signup · proposed filing price is not for sale
Sample, not your facts: Illustrative inputs: Museum morning | 2026-10-01T15:30 | 2026-10-03T10:00; Gallery afternoon | 2026-10-01T15:30 | 2026-10-02T11:00. Purchased duration in whole days = 2. Visits where modeled rules disagree: 1 visits with different window results. All records are invented.
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.
Why the flat version breaks
Treating a duration word as a complete rule
“Two days” does not establish rolling hours, calendar dates or an inclusive expiry boundary. Read the exact terms instead of choosing the favorable model.
Ignoring activation late in the day
A calendar-day rule can use most of day one before the first visit. The comparison exposes that arithmetic but does not change the purchased rule.
Using fixed local hours through a clock change
The model has no time-zone database. Seasonal transitions can alter actual elapsed time, so a provider-confirmed expiry instant is needed in that case.
How to work the validity-window stub
Find the real validity wording
Look for calendar days, rolling hours, activation definition and end-boundary language in the provider’s current terms. Do not assume that all passes for one city use the same convention. The app supplies no real pass duration or policy.
Record local activation and visit labels
Use explicit dates and times in one fixed local clock. A visit before activation is rejected. If rows refer to different hypothetical activation choices, keep each label clear so the comparison does not suggest one pass was activated several times.
Compare the two modeled boundaries
Rolling expiry equals activation plus days times twenty-four hours. Calendar expiry is midnight after the entered number of calendar dates, with activation date included. A visit is inside a model only when it is before expiry; the summary counts rows where those two answers differ.
Confirm bookings independently
Ask the provider which convention actually applies and check attraction reservations and hours. A favorable modeled window cannot create access. Keep confirmation details in your booking records, not in a shared state link.
What the validity-window stub separates
Question
Before
Inspect this instead
Treating a duration word as a complete rule
“Two days” does not establish rolling hours, calendar dates or an inclusive expiry boundary. Read the exact terms instead of choosing the favorable model.
Record local activation and visit labels
Ignoring activation late in the day
A calendar-day rule can use most of day one before the first visit. The comparison exposes that arithmetic but does not change the purchased rule.
Compare the two modeled boundaries
Using fixed local hours through a clock change
The model has no time-zone database. Seasonal transitions can alter actual elapsed time, so a provider-confirmed expiry instant is needed in that case.
Confirm bookings independently
This validity-window stub replaces a manual count or calculation, not source verification or the responsible person’s review.
Run it on the samples, right here
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.
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.
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.
Go deeper: the companion app files the same reading as a punched ticket stubs
The article demo above runs without limits. The companion app keeps a local history, exports the rows as CSV, prints the validity-window stub reading, and holds your drafts on this device — one complete free app run; the proposed $4 one-time filing layer is not for sale.
The validity-window stub answer stays complete for free. The proposed $4 one-time filing layer adds row CSV, print and five local reading summaries, not hidden answers. Checkout is unavailable; the article demo remains unlimited.
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.
What this is built on
Method: Rolling expiry equals activation plus days times twenty-four hours. Calendar expiry is midnight after the entered number of calendar dates, with activation date included. A visit is inside a model only when it is before expiry; the summary counts rows where those two answers differ.
All sample records, dates, quantities and labels are invented. No outside policy, contract, rate, clock offset, measurement or accessibility standard is represented as verified.
Google’s official pricing documentation, fetched 2026-09-30, says AI Studio is free in available regions. Optional formatting may require a Google account; manual local entry requires none. Limits can change and free-tier content may be used to improve products. Do not send private records.
Before: the phrase two days hid the activation convention. After: rolling and calendar expiry boundaries are visible as two hypothetical models, not entry permission.
Setting: Purchased duration in whole days = 2. Expected summary: 1 visits with different window results.
Two rolling twenty-four-hour days activated October 1 at 15:30 end October 3 at 15:30. Two calendar days counting activation day end at the start of October 3 instead. Museum morning at 10:00 on October 3 lies inside the rolling window but outside the calendar-day window, so one visit differs. Gallery afternoon lies inside both. The displayed hours remaining belong to the rolling model; the row note separately names the calendar end and each model’s result.
Sample B — changed plan
Late gallery | 2026-10-01T08:00 | 2026-10-02T23:00
Next-day museum | 2026-10-01T08:00 | 2026-10-03T09:00
Setting: Purchased duration in whole days = 2. Expected summary: 0 visits with different window results.
Late gallery is before both the October 3 midnight calendar expiry and the October 3 08:00 rolling expiry. Next-day museum is after both. Neither visit differs between the two conventions, even though the expiry instants are eight modeled clock-hours apart. Zero disagreements does not prove the pass is valid: attraction exclusions, reservation requirements, opening times and the provider’s actual definition still need checking.
Setting: Purchased duration in whole days = 2. Expected summary: 0 visits with different window results.
At midnight activation the two modeled expiry boundaries coincide. Exactly at expiry, both windows are closed because the comparison is strictly before the end. One minute earlier is inside both. A provider could define a different end-boundary rule; this test makes the model’s rule explicit rather than assuming that a displayed zero hours means entry remains available. All local timestamps here use one constant clock offset, so seasonal clock changes are intentionally excluded.
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.