Calendar Events

The FOMC analysis closed the open design questions this document left open. The decided shape (story * Decisions D1, D4):

• One table for all event kinds. A new calendar_event entity (ores.refdata, codegen'd, bitemporal, sibling of calendar_rules=/=calendar_exceptions): id (uuid), calendar_code → calendars, event_date (date), diary_entry_type → new diary_entry_types vocabulary, name, description (nullable), source (nullable provenance, e.g. 'federalreserve.gov'), plus the standard audit/temporal columns. Never a table per calendar or per type.
• The vocabulary. diary_entry_types seeds holiday, central_bank_meeting, data_release, other — open-ended; a future kind (earnings release, auction) costs one row.
• Holidays keep their own machinery. calendar_rules, calendar_exceptions and the calendar_date grid stay as they are; calendar_event holds the non-holiday kinds. The holiday entry type stays in the vocabulary so the whole classification lives in one place.
• Template/Instance. An event row is an instance; its template is the (calendar, diary_entry_type, name) triple. FOMC meetings are entered as a short run of instances. Formulaic recurrence generation (e.g. Non-Farm Payrolls) is deferred; calendar_rules's grammar can later feed a template link if a consumer needs it.
• The worked case. US.FOMC is a row in calendars (calendar_type central_bank_meeting, country_code US, source federalreserve.gov, is_editable true); currency_calendars links USD to it; the 2025–2027 meeting dates are seeded as central_bank_meeting calendar_event rows, transcribed from federalreserve.gov/monetarypolicy/fomccalendars.htm with source'federalreserve.gov'=. No formal feed exists — transcription with the citable source, per the survey below.

The code model is documented in Tenor and Curve Bootstrapping Architecture.

An event's time is anchored as an interval — a start and an end, recorded in local time because the event is relative to a country or market. A captured event therefore needs, at minimum, a time zone, a start date/time, an end date/time (equal to the start for a point event such as a data release, distinct for something with genuine duration such as a public holiday observed as a full trading day), a computed UTC start/end pair derived from the two, and a name. The shape is deliberately minimal: an event entry records that something happens, when, and to which currencies, and stops there — no variance weighting, no deliverability-restriction typing, no P&L attribution. Those belong to the Effects side, per The Diary/Effects Model, attached by reference from whichever downstream consumer needs them (the FX vol surface, most plausibly).

The calendar entity needs a type discriminator: is a given entry a public holiday, a central-bank meeting, or an "event" in some more generic sense? A single worked example makes the need for classification concrete: a Non-Farm Payrolls release, a central-bank policy decision (itself a recurring, dated, well-known fixture — the FOMC, the ECB Governing Council and the Bank of England MPC all publish their meeting calendars a year or more in advance), and an unscheduled, market-moving announcement are all qualitatively different kinds of "event." Collapsing all of these into a bare "Event" with no further classification would lose information a consumer might reasonably want to filter on (a trader wanting only central-bank meetings visible on a date picker, say, without every scheduled data release cluttering the view).

The natural shape is a small, open-ended diary_entry_type code — holiday, central_bank_meeting, data_release, other as a plausible starting enumeration — rather than a hard boolean split between "holiday" and "event." This keeps the classification open to extension (a future earnings_release or auction type costs nothing to add), and lets a central_bank_meeting entry carry the same shape as every other event while still being filterable and reportable on its own. The layout question is settled (2026-08-09): holidays keep the recurrence machinery (calendar_rules, calendar_exceptions, calendar_date) and events live in one calendar_event table — the holiday type remains in the diary_entry_types vocabulary so the classification is unified even though the physical homes differ. See "the landed model" above.

Events inherit the same Template/Instance pairing as holidays (see Holiday Calendar Administration): templates for events are instantiated as the events occur, following the same recurring-appointment principle described there. A central-bank meeting is, in this respect, the clean textbook case for a template: the FOMC holds eight regularly scheduled meetings a year, on dates announced well in advance but not reducible to a single closed-form recurrence rule (the exact dates shift year to year for scheduling reasons), so in practice each year's calendar is entered as a short run of instances against a lightweight "FOMC meeting" template, rather than computed from a formula. Non-Farm Payrolls, by contrast, is formulaic (first Friday of the month) and could be templated more tightly. Both are accommodated by the same Template/Instance mechanism without requiring the system to distinguish "formula-derivable" from "externally announced" events at the schema level.

Populating the events table with real, citable data — rather than purely synthetic fixtures — is straightforward for the major central banks, each of which publishes its policy-meeting calendar as an official, machine-consultable web page (none currently offers a formal iCal/ICS feed directly from the central bank itself, so ingestion means scraping or hand-transcribing the published table rather than subscribing to a feed):

• The Federal Reserve publishes the FOMC's meeting calendar, including links to the resulting policy statements and minutes, at federalreserve.gov/monetarypolicy/fomccalendars.htm. The FOMC holds eight regularly scheduled meetings a year, with additional unscheduled meetings held as needed — the latter a reminder that even a "regularly scheduled" central-bank calendar can admit ad hoc, out-of-template instances.
• The European Central Bank publishes the schedule of Governing Council and General Council meetings, including monetary-policy decision and press-conference timings, at ecb.europa.eu/press/calendars/mgcgc.
• The Bank of England publishes upcoming Monetary Policy Committee dates — the announcement of the Bank Rate decision and the publication of MPC minutes — at bankofengland.co.uk/monetary-policy/upcoming-mpc-dates.
• The Bank of Japan publishes the scheduled dates of its Monetary Policy Meetings, held eight times a year over two consecutive days each, at boj.or.jp/en/mopo/mpmsche_minu.
• The Bank of Canada publishes its full-year schedule of policy interest rate announcements (eight per year, each at a fixed 9:45am ET slot) the preceding August, at bankofcanada.ca/press/upcoming-events.
• The Reserve Bank of Australia publishes its Monetary Policy Board meeting schedule (eight two-day meetings a year, decision announced 2:30pm AEDT/AEST on the second day) at rba.gov.au/schedules-events/board-meeting-schedules.html.
• The Swiss National Bank publishes its quarterly monetary policy assessment dates (March, June, September, December; decision at 9:30am CET) at snb.ch/en/the-snb/mandates-goals/monetary-policy/decisions.

Together these seven sources cover the G10 policy calendars (Fed, ECB, BoE, BoJ, BoC, RBA, SNB); none publishes a formal iCal/ICS feed, so populating a table from them means manual or scripted transcription rather than an automatable ongoing sync.