Skip to content

Days to open as the axis when a show moves in the calendar

Forecasting methodsUpdated 2026-08-238 min read

In short

A days to open axis re-indexes each edition so that day zero is the day doors open and day 180 is six months earlier. Editions held at different times of year then line up against each other, and calendar effects such as a moving Easter come back as separate regressors on the open date.

The show moved from March to June. The pacing report still plots registrations against the calendar week, so the chart shows last year's campaign finishing in week 11 and this year's still climbing in week 20, and the year on year comparison line is meaningless from January onwards.

Somebody in the meeting will say we are 40 per cent behind. On that chart, in that week, they are. On any reading that matters, the number tells you nothing except that the show moved, which everyone already knew.

The days to open axis is the fix, and it is a change of coordinates rather than a model.

Re-index every edition on days to open

Define one variable and use it everywhere. Day zero is the day doors open. Day 180 is 180 days before doors. Every snapshot, every daily arrival count, every price tier boundary gets a days-to-open value instead of a date.

The 2025 edition of a furniture show opened on 12 March, which is the 71st day of that year. The 2026 edition opens on 9 June, the 160th day. The two are 89 days apart in the calendar, which is the number that makes every date-based comparison useless and which the new axis absorbs completely.

Once both editions are indexed this way, day 60 of the 2025 campaign and day 60 of the 2026 campaign are the same point in each show's own lifecycle. The comparison you wanted is now a subtraction.

This convention comes straight from reservation forecasting, where the equivalent variable is days to departure or lead time. Everything in that literature, from booking curves to pickup increments, is indexed on it, and the reason is the same: an airline seat forty days from departure behaves like other seats forty days from departure regardless of which month the flight is in.

What breaks when you compare 20 January to 20 January?

The snapshot on 20 January 2025 was taken 51 days before the March show opened. The snapshot on 20 January 2026 was taken 140 days before the June show opens.

So the year on year comparison is putting a campaign that is seven weeks from doors next to a campaign that is four and a half months out. On any show with a normal booking curve, the first will be holding twice or three times what the second is holding, and the 40 per cent gap in the meeting is an artefact of the calendar with no demand content at all.

Fix the axis and the comparison becomes tractable. Day 51 for the 2026 edition falls on 19 April 2026, so the honest comparison for the 20 January 2025 snapshot is the 19 April 2026 snapshot, which does not exist yet. That is a genuinely uncomfortable answer and it is the correct one. When a show moves later in the year, part of its history stops being comparable until the campaign catches up, and reporting a gap in the interim means reporting a gap you invented.

The same logic applies to price tiers. If the early bird closed at day 90 in 2025 and at day 62 in 2026, those deadlines are 28 days apart on the axis that matters, and any comparison that ignores that is comparing a post-deadline count with a pre-deadline one.

Putting the calendar back as a regressor

Re-indexing removes calendar effects from the axis, which means it removes them from the model unless you put them back.

The mechanism is a regression term keyed to the actual date that each days-to-open value falls on. Hyndman and Athanasopoulos list the standard set in the third edition of Forecasting: Principles and Practice (2021), in a section on useful predictors for time series regression: a trend, dummy variables, seasonal dummies, intervention variables for one-off events, trading day counts, distributed lags, an Easter indicator, and Fourier terms for periodic patterns. Every one of those has an event reading.

Easter is the instructive one because it moves. In 2025 it fell on 20 April, 39 days after the March show had already opened, so it sat entirely outside that edition's registration window. In 2026 it falls on 5 April, 65 days before the June show opens, so it sits squarely inside the window during the period when the campaign should be accelerating. Two editions of the same show, and a public holiday that is outside the campaign in one and inside it in the other. Hyndman and Athanasopoulos make the general point plainly, noting that Easter differs from most holidays because "it is not held on the same date each year".

The Census Bureau treats this as a first-class problem. Its X-13ARIMA-SEATS seasonal adjustment software, which the Bureau produces and maintains, is built around regARIMA models, meaning linear regression with ARIMA errors, and it ships a utility for generating user-defined moving holiday regressors precisely so that effects like Easter can be estimated separately from the seasonal pattern. The architecture is the one to copy: a systematic component on the lifecycle axis, plus regressors for the calendar events that happen to land inside the window.

Which calendar effects actually move a registration curve?

Four are worth carrying and the rest are noise on most shows.

Day of week matters at the daily level. Business registrations arrive on weekdays, and a campaign measured daily has a strong weekly cycle that has nothing to do with pacing. If you are modelling daily arrivals rather than weekly cumulative counts, put in the day of week or you will attribute the Saturday trough to a loss of momentum.

Public holidays inside the window suppress arrivals for a few days and usually give some of it back afterwards. A single dummy on the day is normally too narrow, since the effect leaks into the days either side.

The summer break is the largest single effect on European B2B shows and it is a block rather than a day. An August that sits at days 120 to 90 of one campaign and days 200 to 170 of another affects a completely different part of the curve in each case, which is exactly what the days-to-open axis makes visible and what a calendar axis hides.

Competing events in the sector are the fourth, and they are a genuine intervention variable: a dated, known, one-off suppression of your registration rate while your audience is at somebody else's show.

Estimating how much a move from March to June changes underlying demand, as opposed to shifting the curve, is a separate question and a harder one, and the demand effect of a date change belongs to O33. The axis work here is a prerequisite for it and does not answer it.

The two axes you now have to maintain

The practical cost of this convention is that every snapshot row needs two keys and both have to be right.

Store the snapshot date and derive the days-to-open value from the edition's open date. Do not store the days-to-open value alone, because show dates change after registration has opened, sometimes twice, and a derived column can be recomputed while a stored one silently becomes a lie. I have seen a pacing model run for a full season on days-to-open values computed against a show date that had moved by nine days in February.

Two smaller rules save trouble later. Fix the meaning of day zero as the first day the show is open to visitors, since move-in days and press previews create ambiguity, and write it down. And define the days-to-open value for a snapshot taken during the show as negative, since some registrations arrive on site and truncating them at zero throws away the onsite tail.

Once every edition is on the same axis, the stacking operations become available. A decomposition of the curves into shared components needs a common horizontal scale to work on, which is O7's territory, and it will produce components that mean nothing at all if the alignment is wrong.

Where this stops

A common axis makes editions comparable and does not make them the same.

The largest remaining problem is that days to open assumes both campaigns had the same amount of runway. An edition that opened registration 210 days before doors and an edition that opened 150 days before doors do not have a comparable day 180, because one of them had no registration system running at that point. The axis lines them up and the zeros at the start of the shorter campaign are structural rather than behavioural, and rescaling or truncating the windows is O10's subject and needs settling before any of this is trustworthy.

The second is that day zero itself is not always a clean boundary. Shows that run three days accumulate onsite registrations across all three, and a show whose second day falls on a public holiday has a different onsite tail from one whose second day is a Tuesday. Indexing to the first open day is the right default and it flattens a real difference.

The third is subtler and worth naming because it catches people who have done everything else right. Re-indexing makes the horizontal axis comparable and does nothing about the vertical one. Two editions aligned perfectly on days to open can still be incomparable because one of them counted exhibitor staff as registrations and the other did not. The coordinate change is necessary and it is not sufficient, and it can make an inconsistent measure look like a clean trend.

Add a days-to-open column to your snapshot table this week, derived rather than stored, and rebuild the year on year pacing chart against it. If the chart changes shape at all, every pacing comparison your team has made since the show moved was measuring the calendar, and the corrected version is the one to take into the rest of your forecasting methods work.

Questions people ask about days to open axis

Why re-index registration data by days to open?
Because a campaign's position in its own lifecycle drives registration volume far more than the month does. A show that moved from March to June has two editions whose calendar dates never overlap in a useful way, and re-indexing so that day zero is show open puts both campaigns on a common horizontal scale.
What happens to seasonality once you use a days to open axis?
It stops being automatic and becomes something you model explicitly. Once every edition is indexed to its own opening day, the fact that one campaign ran through August and another did not is invisible to the axis. Put it back as a regressor keyed to the calendar date each days-to-open value corresponds to.
How far out should the days to open axis start?
At the earliest registration open date across the editions you are comparing, and no earlier. Starting at day 365 when three of your five editions opened registration at day 180 fills the early part of the axis with structural zeros that a smoother will read as very slow demand rather than as a closed registration system.

Related reading

All forecasting methods articles