The conventional implementations (statsmodels or pmdarima in Python, stats in R) do their job well: they estimate SARIMA via likelihood, select orders automatically, and produce sensible forecasts for series with trend and one seasonality. Monthly or quarterly demand data is their home ground. The problems start when the data has more than one cycle: the classical SARIMA formulation has a slot for exactly one seasonal lag, so for the half-hourly electricity demand you would have to pick either the hour-of-day or the day-of-week cycle and discard the other.

MSARIMA (Multiple Seasonal ARIMA) solves this by reformulating ARIMA in the Single Source of Error (SSOE) state space form. Each AR, I, and MA element becomes a state in the model, so nothing restricts you to one seasonal lag: you can have as many as you want. In the smooth package, orders are specified per lag, matched to a lags list. Here is an example on the classical taylor series (half-hourly electricity demand in England and Wales), with two seasonal cycles:

from fcompdata import taylor
from smooth import MSARIMA

# MSARIMA(3,0,1)(0,1,1)[48](0,1,1)[336] model = MSARIMA(
orders={"ar": [3, 0, 0], "i": [0, 1, 1], "ma": [1, 1, 1]},
lags=[1, 48, 336],
h=336, holdout=True
)
model.fit(taylor.y)
model.predict(h=336, interval="prediction", level=0.95)

In Python, it takes only 1.5 seconds for the function to fit the model to the data and estimate its parameters, which is fast for a double-seasonal model fit to roughly four thousand observations:

But the smooth implementation brings several additional practical benefits.

First, model.fit() accepts a matrix of external regressors via xreg, estimated jointly with the ARIMA components – no separate pre-filtering step. The logic and the code are identical to ETSX, which I covered earlier.

Second, you can swap the loss: loss=”GTMSE” or “MSEh” optimises the model directly on multistep errors, with the same shrinkage mechanism I discussed in the post on multistep losses.

Third, you don’t need to stick with the Gaussian distribution – you can choose other ones if you think that, for example, Laplace is more suitable for the data (this post).

And there is one more thing. Because MSARIMA now lives in the same state space framework as ETS, the two models can be combined into one and compared with each other directly via information criteria. But that deserves a post of its own, so stay tuned.

Read Chapter 9 on ADAM ARIMA.
Or check out the documentation in smooth wiki.

An why not try it yourself? pip install smooth

Message smooth in python: Multiple Seasonal ARIMA first appeared on OpenForecast.

It is called “Seasonal Naïve”. While the simple Naïve copies the last observed actual into the future as a forecast, the seasonal one copies the whole seasonal shape of the data and uses it as a forecast. The logic is straightforward: if you see an increase in sales every January, why not use the actual sales of January 2025 as the forecast for January 2026? Simple, easy to do, and hard to beat in some cases, especially when your demand does not have high variability.

What this method doesn’t do is filter out the noise in the data. This means that if you had a promotion-driven spike this February, Seasonal Naïve will happily copy it into next February’s forecast. So, if you have some distinct components in your time series and/or effects of explanatory variables on sales, Seasonal Naïve might not be a good choice. But it remains an essential benchmark for any seasonal data.

I actually have an anecdote related to the Seasonal Naïve. Yves Sagaert and I were working on a paper, and we decided to apply our new method to data with multiple seasonality. It worked great, better than the double seasonal exponential smoothing and ARIMA. I was really hyped and was ready to celebrate, when Yves suggested trying the Seasonal Naïve as well. It’s good that he did, because it turned out that Seasonal Naïve beat them all, including our new method, without even blinking. This was a great demonstration of a principle I had been preaching to others: if you have seasonal data, always use Seasonal Naïve as a benchmark.

In the Demand Forecasting Principles course in November, we cover simple methods like this one properly, including when to stop trusting them. Details and booking can be found here.

Message Another important Naïve method first appeared on OpenForecast.

The core idea is simple and neat. For this example, I’ll use monthly data, like the time series in this image:

You can see that the data has strong seasonality, and we can qualitatively say that capturing that seasonal component correctly will probably solve the main problem in capturing the structure. But how can we quantify this?

All you need to do is put the data in a “wide” format, with months in rows and years in columns. Then, as Hans proposed, run a two-way ANOVA with “month” and “year” to capture variability due to year (trend) and due to month (seasonality). Roughly, we take row/column means to get mean seasonal profiles and mean annual changes (trend), as in the following two images:

The former has no trend, the latter has no seasonality, so they can be analysed separately. Then we calculate the sums of squares of these means from the global mean to estimate variation due to months (seasonality) and years (trend). We can also calculate the sum of squares of the irregular component (what is left), giving three elements that add up to the total sum of squares.

Next step is trivial and straightforward: calculate the shares of each component in the total sum of squares. For our example, using aov() in R and then computing the total:

Seasonal:  292,307,558
Trend:     176,308,365
Irregular:  33,618,630

Total:     502,234,552

So, the seasonal contribution is 292,307,558 / 502,234,552 ≈ 58.2%, the trend contribution is 35.1%, and the irregular component is 6.69%.

Why bother? This simple EDA technique tells you roughly what to focus in forecasting. In this example, capturing seasonality correctly is roughly 60% of the story, with trend being second in importance. Hans goes further in his derivations, see his LinkedIn post. He also analysed M3 results at some point, explaining why some methods performed better (trend dominated the data).

It is worth pointing out that this approach assumes that the seasonal component does not evolve over time, which is reasonable but not always correct. And the model behind this is essentially a regression with dummy variables for year and month. Nonetheless, it is a great starting point for EDA.

P.S. Hans Levenbach passed away on 7 April 2026. I wasn’t sure whether to write about it and what to write about him, but I had several nice discussions with him, and I have admired his approach to forecasting: first explore the data, then build a model. His passing is a loss for the forecasting community.

P.P.S. You can read a bit about him on the IIF website.

CMAF had a webinar with Hans a couple of years ago. We had technical issues, but he managed to explain his idea well.

Message Hans Levenbach’s classification scheme for trend/seasonal components first appeared on OpenForecast.

I’ve worked with a couple of companies where there were some examples of data with drastically changing seasonal patterns over just a few years. For example, Before Covid (BC), the consumer behaviour could be different than After the Disruption (AD): people started ordering online some products that they used to buy in shops. Some practitioners told me that the seasonal patterns in their data had changed so dramatically that historical data BC had become practically useless.

Why is this important?

If you don’t recognise that the seasonal patterns can change and simply use seasonal dummy variables (for example, in regression or decision trees), you’ll run into problems, as these approaches won’t capture the evolving profile. The same applies to classical decomposition (see Section 3.2 of ADAM), since it assumes a fixed seasonal structure. In fact, any model that assumes fixed seasonality would fail in this situation, and you may not even notice (see image in the post, where the model fails to capture the profile correctly because it assumes that it is fixed).

What can we do with that?

The solution is to use approaches that allow seasonality to evolve over time. ARIMA and ETS handle this via their parameters, while STL decomposition produces a dynamic seasonal profile. In regression or decision trees, you could incorporate lagged sales to partially account for this, or bring in the seasonal component from STL/ETS as an additional feature.

All good? Not quite, because there is a nasty small grey elephant hidden in this room.

Even if your chosen method allows seasonality to evolve, you must ensure that forecasting uncertainty reflects this properly. If the seasonal pattern in your training set changed drastically, what prevents it from shifting again in the test set? This is particularly critical if you need predictive distributions, such as for setting safety stock levels or generating prediction intervals. Ignoring the fact that the seasonality might change further could make your predictive distribution narrower than expected, leading to potential lost sales.

The good news: ARIMA and ETS handle this naturally, as components’ uncertainty translates directly to the holdout variance. In ML, it is more complicated, because you would need to invest time in proper feature engineering to explicitly capture the potential seasonality changes. Unfortunately, I haven’t done much in the latter direction, so I cannot give you a good recipe. Any thoughts what to do here?

And what do you do in the situation like that?

Message Evolving seasonality first appeared on OpenForecast.

I’m talking about the seasonal pattern that shifts over time. What I mean is that, for example, instead of having the standard number of observations in the cycle (e.g., 24 hours in a day), in some cases you can have more or fewer of them. How is that possible?

One of these issues is the Daylight Saving Time (DST) change. The original idea of DST was to reduce energy consumption because daylight in summer is longer than in winter (there’s a nice and long article on Wikipedia about it). Because of this, many countries introduced a time shift: in spring, the clock is moved forward by one hour, while in autumn it goes back. This idea had a reasonable motivation at the beginning of the 20th century, but I personally think that as we’ve progressed as a society, it has lost its value. While this is already extremely annoying on its own, a bit unhealthy (several studies report an increased risk of heart attacks), and a torture for parents with small kids (the little ones don’t understand that it’s not 7am yet), it also introduces a modelling challenge: two days in the year do not have 24 hours. In spring, we have 23 hours, while in autumn we have 25. Standard classical forecasting approaches (such as ETS/ARIMA, regression, STL or classical decomposition) break in this case, because by default they assume that a specific pattern repeats itself every 24 hours. The issue arises because business cycles are tuned to working hours, not to the movement of the sun – people come to work at 9am, no matter how many hours are in the day.

Another challenge is leap years. While DST is totally man-made, leap years occur because the Earth orbits the sun approximately every 365.25 days. To avoid drifting too far from reality, our calendars include one extra day every four years (29th February). This addresses the issue but also means that one year has 366 days instead of 365. Once again, conventional models relying on fixed periodicity fail.

There are several ways to handle this, all with their own advantages and disadvantages:

1. Fix the data. In the case of DST, this means removing one of the duplicated hours during the autumn time change and adding one during the spring shift. For leap years, it means dropping the 29th of February. This is easy to do, but breaks the structure and might cause issues when we have DST/leap year in the holdout sample.
2. Introduce more complex components, such as Fourier-based ones, to capture the shift in the data. This works well for leap years but doesn’t address the DST issue. Harmonic regressions and TBATS do this, for example.
3. Shift seasonal indices when the issue happens – for example, having two indices for 1am when the switch to winter time occurs.

In R, I’ve developed the temporaldummy() function in the greybox package to introduce correct dummy variables for data with shifting seasonality, and I’ve incorporated method (3) into the adam() function from the smooth package. You can read more about these here: https://openforecast.org/adam/MultipleFrequenciesDSTandLeap.html

Are there any other strategies? Which one do you prefer?

BTW, Kandrika Pritularga and I are running a course on Demand Forecasting Principles with Examples in R. We’ll discuss some of these aspects there. Read more about it here.

Message Challenges related to seasonal data: shifting seasonality first appeared on OpenForecast.

First things first: when we say “seasonality” in forecasting, we mean any pattern that repeats periodically. If you mention monthly seasonality, most people will understand that you’re referring to a pattern repeating every 12 observations. Similarly, quarterly seasonality is widely recognized. However, beyond these two simple cases, ambiguity creeps in.

For example, if you describe your data as having “weekly” seasonality, do you mean that you’re working with weekly data and observe similar patterns every 52 weeks? Or are you dealing with daily data, where the pattern repeats every 7 days? The same issue applies to the term “daily” seasonality, which can refer to a pattern within daily data or a repeating pattern across multiple days.

Furthermore, the more granular your data, the more potential seasonal profiles you can have. For daily data, you may observe seasonality at 7-day (weekly) and 365-day (yearly) intervals. For hourly data, you could have three seasonal patterns: 24 hours, 168 hours (24 × 7), and 8,760 hours (24 × 365). An example of such data is shown in the image attached to this post.

Some people use the prefix “intra” to indicate patterns within a given frequency, but I still find this confusing. For example, intraweekly only indicates that a pattern exists within the week but doesn’t specify the frequency: it could refer to either 7 days or 168 hours.

That’s why I personally prefer the “A of B” naming scheme for seasonality. For example, “week of year” seasonality clearly denotes a pattern repeating every 52 observations. “Day of week” clearly refers to a 7-observation pattern. This format is more precise and less ambiguous than “weekly” or “intraweekly” seasonality. “Hour of year”, “half-hour of week”, “minute of day” etc are all straightforward and easy to understand.

And what naming conventions do you use?

P.S. Kandrika Pritularga and I are running the course “Demand Forecasting Principles with Examples in R” again, where we’ll discuss some of these and related aspects in detail. You can read more about the course and sign up for it here and here respectively.

Message Naming conventions for seasonality types first appeared on OpenForecast.

First things first, in forecasting, the term “seasonality” refers to any natural pattern repeating with some periodicity. For example, if you work in a hospital with A&E attendance, you know that every Monday has higher demand than other days, while weekends tend to have lower demand. This is a well known phenomenon: people have fun over the weekend and then go to hospital first thing in the morning of the work week, so if you don’t want to get stuck in the hospital, don’t injure yourselves over the weekend!

Anyway, back to the main topic of this post!

Consider the following example:

This is a daily data. Is it seasonal? Without context, you might assume so: there’s a midweek peak followed by a decline, repeating weekly, so it must be seasonal, right? But what if I told you that this data is daily LinkedIn impressions of my posts? The peaks coincide with posts releases, and it is hard to tell from the image, but I released first three posts on Thursdays and then switched to Wednesdays, shifting peaks one day forward. So, this is not a seasonal data, but instead it is a classical life cycle (which can be described, for example, by the Bass model), repeating every week. It would be seasonal if the impressions happened naturally without me releasing anything. For example, number of visitors of my website has natural seasonality, because they happen without my interventions:

Bringing this to a business context, I have encountered several times the “spurious seasonality”. For example, one company, working with weekly data, used a seasonal model with periodicity of 4, because they noticed that at the end of each month, people get their salary and spend it, increasing the sales of the company. However this is not true seasonality, but rather a calendar event that happens seemingly periodically, on a specific day of month (not necessarily the same one).

Why is this important?

Relying on a seasonal model (like seasonal ETS or ARIMA) in such cases poses risks. If the periodicity shifts (e.g., salaries received on a different week), the model will produce misaligned forecasts (e.g., predicting an earlier peak). To address this, you should model such events with explanatory variables instead of seasonal indices. This way you will be able to control the timing of the event in your model and adjust it if needed.

So, next time you see a pattern that looks seasonal, think whether it happens naturally, or whether you are dealing with the spurious seasonality. Remember, the context is always important!

Message Seasonal or not? first appeared on OpenForecast.