What a Date on Our Calendar Means

---

Most event listings are copied. Ours are checked, on a schedule, against the body that issues the date — and when a check fails we say which of the several different ways it failed, because "we couldn't confirm it" and "the organiser's website no longer exists" are not the same news. This page is the method, written down so you can hold us to it.

The short version

Every event on our calendar carries three things that most listings do not: the issuing authority's own page, the date we last opened that page, and a confidence value. If a date has not been checked recently enough, that is visible to us as a queue item rather than invisible to you as a stale line.

We publish from a register of 114 sources — 90 of them the issuing authority's own site — each carrying a written scope and a status. Of those, 75 are approved outright; the rest are conditional, restricted to proving that a thing exists, quarantined or retired. A source that may prove an event exists is not automatically a source that may set its date.

The rule the whole thing rests on

A run that cannot open a source must say so, and must not touch the date.

That sounds obvious. It is the hardest rule to keep, because a process that cannot see anything produces a clean-looking report about nothing — and a clean report is indistinguishable from a good one until a reader turns up somewhere on the wrong day.

So the automated pass is allowed to change exactly five things without opening a source, and no others:

1. Roll an occurrence into the past because its date is behind today. That is arithmetic.
2. Archive an event whose occurrences have all passed. The event is never deleted — it moves to the archive.
3. Create a new occurrence from a repeat rule already stored on that event's own row — and the new occurrence has to carry a note saying the date came from the stored rule and not from anybody reading a page.
4. Regenerate the published views.
5. Write its own receipt.

Everything else needs somebody to open the source.

Three ways a source can fail, and why we distinguish them

When a check cannot be completed, the outcome is recorded as one of these, because they mean different things and deserve different responses:

And a fourth, which must never be filed as any of the three: the request never left the machine. No lookup happened, nobody refused us, nothing timed out. Recording that as "blocked" would be inventing a finding about a site nobody contacted — a fabricated negative, which is worse than a missing positive because it looks like work.

The year trap, which catches everybody

We read the year off the date field. Never off the title, the slug, or the domain.

Italian institutions republish. A festival page at a 2026 address routinely serves the 2024 programme, and a page that prints "16 August, Sunday" is telling you the year even when it does not name it — 16 August 2024 was a Friday.

This is not theoretical. In August 2026 the Comune's own un-suffixed page for the Palio timetable was still the 2024 notice, with 2024's times on it. A listing that lifted those times would have looked completely normal and sent people to the Campo at the wrong hour. The check that caught it was the weekday.

What "provisional" means when you see it

Some future dates are marked provisional. That is not hedging — it is a specific claim: the date follows a rule we hold, and no authority has yet published it.

The Palio runs on 2 July and 16 August, and the horse handover falls three days before the August race. Those are dependable enough to plan a year around and not yet published for next year, so they appear with the flag on until the Comune says so itself. When the announcement lands, the flag comes off and the date's source becomes the announcement.

The opposite also happens, and matters more: an event that has passed does not silently vanish, and a cancelled one is recorded as cancelled rather than removed. Deleting is how a calendar quietly rewrites its own history.

Why nothing on this page has a date on it

You will notice that this page names no festival dates, and neither do our seasonal guides. That is deliberate and it is the rule the whole cluster obeys:

The articles carry the pattern. The calendar carries the instance.

A date written into prose is frozen the moment it is published, and every one of them rots on its own schedule while looking exactly as authoritative as it did on day one. A date on the calendar is attached to a source and a last-checked stamp, and something is watching it.

So when a guide here tells you the antiques market is on the third Sunday, or that the trial races run morning and evening in the days before the Palio, that is the pattern — and it sends you to the calendar for the day.

What this method cannot do

Three limits, stated plainly, because a method page that lists only its strengths is marketing:

• It cannot cover everything. The calendar holds what we have verified, not a census of everything happening in the province. An event's absence is not evidence it is not happening.
• It cannot see a change nobody published. If an organiser moves a concert and tells only its own mailing list, our check against their site will pass and be wrong. For anything you are travelling for, the organiser's own page on the day is still the last word.
• It cannot make a source honest. We verify that the issuing body said it. Where the issuing body itself is unclear, we say the claim is unclear rather than tidying it up.

Continue Reading

• The Siena & Tuscany notice board — the calendar itself, with sources and dates
• The shape of the Sienese year — when things happen here, and what genuinely recurs
• Past events archive — nothing is deleted
• Our editorial standards — how the rest of the site is checked

Sources

This page describes our own method, so its sources are internal ones — the rules we work to and the records our checks leave behind. They are named here for the same reason we name external ones: a claim without a source is an assertion.

• Our events governance rules — the verification transport rule, the five things a run may change without opening a source, the three source-failure outcomes and the fourth that must never be confused with them, the source statuses, and the year rule
• Our permitted-source list — what the site is allowed to verify against, and the standing instruction never to route around a blocked source
• The source register — 114 hosts, of which 75 approved, 26 conditional, 3 discovery-only, 8 quarantined and 2 retired; 90 are the issuing authority's own site. Each carries a written scope and a status
• The events master — one row per event, each carrying its official source URL, the date we last opened it, a confidence value and its occurrences
• The run receipts — written by every scheduled run, pass or fail, recording which sources were opened and which rows were touched

The counts above are not typed in. They are computed from the register itself every time the site is built, and the build fails if the copy and the register disagree — because when they were typed in, they drifted, and for four weeks this page understated its own register by twenty-seven sources.

By the Siena & Toscana editors