The Diary/Effects Model

A diary entry — whether a public holiday or a market event — needs to capture only the time point at which something happens: a date (or, for an event, an interval; see Calendar Events) and little else. It does not encode why the entry matters to any particular downstream system, because the same entry can matter to several systems in entirely different ways at once — a central bank rate decision is simultaneously a volatility event, a possible deliverability disruption, and (if it falls on what would otherwise be a business day) irrelevant to settlement timing altogether. Baking any one of those interpretations into the diary entry itself would privilege one consumer over the others and make the entry harder to reuse.

An effect is a downstream, typed impact attached to a diary entry. For volatility specifically, the effect would carry a variance increment — a weighting multiplier applied for the duration of the event — and could in principle span multiple currency pairs and multiple market data types at once. The premise that scheduled announcements measurably drive volatility is well established empirically: Ederington and Lee's study of interest rate and FX futures markets found that scheduled macroeconomic announcements account for most of the observed intraday and day-of-week volatility patterns in those markets (Ederington & Lee, 1993), and more recent work quantifies the same effect specifically for FX volatility across a range of macro event types (Martins & Lopes, "What events matter for exchange rate volatility?", 2024). The general methodology for measuring an event's effect on a market variable — comparing observed behaviour around the event to a counterfactual baseline — is the event study, formalised in Kothari & Warner, "Econometrics of Event Studies". Critically, effects are decoupled from one another: the volatility effect of an event is modelled independently of its deliverability effect and of any delivery-date impact, so one diary entry can drive several independent, differently-typed downstream consequences without those consequences needing to agree on a shared representation.

Effects, like holidays (see Holiday Calendar Administration), would follow a Template/Instance pairing: templates for events and effects are instantiated as the events occur, so editing the template changes every future occurrence, while editing a specific instance changes only that one — the same principle as a recurring appointment in a calendar application, which is as good a mental model as any for a reader unfamiliar with the finance-specific vocabulary.

A concrete illustration: a Non-Farm Payrolls release could carry a currency-pair weighting matrix (cross-weights across USD/GBP/EUR/CAD/AUD, say) as its effect. The diary entry is simply "Non-Farm Payrolls, first Friday of the month, 13:30 UTC"; the effect — the weighting matrix — would be a separate, typed object referencing that entry, not a field on it.

Effects are numerous and heterogeneous, and belong to the consuming subsystem (a vol surface, a deliverability check, a P&L attribution), not to the calendar itself. A calendar entity, and any event table layered onto it (see Calendar Events), is therefore best scoped as the diary — codes, names, dates, and (for events) a time point and the currencies it touches — rather than accreting typed columns for every possible effect. An effect — a variance increment on the FX vol surface, for instance — attaches to a diary entry by reference, keeping the calendar and calendar-event schema stable regardless of how many kinds of effect are later modelled.

An alternative worth noting is to collapse the Holiday/Event distinction entirely into the Effects mechanism, by modelling a holiday simply as an event with a −100% effect on trading activity. That is an elegant simplification once a system already has a fully built-out Effects layer; the pragmatic Holiday/Event split retained in Calendar Events instead treats holidays and events as siblings under the same diary, each carrying its own minimal shape.