Twice a year, most forecasters brace themselves for the spring and autumn. Forecasting is already a complex task, but it becomes even more challenging around daylight saving time (DST) changes. While overall volumes may remain relatively stable, intra-day patterns shift, making it hard to predict how many people will be calling an hour early or later because of the changes. This can lead to misalignment between forecasted and actual call distributions throughout the day. It becomes especially complicated for international call centres serving regions like the EU and the US, which don’t switch time at the same moment. As a result, historical data can suddenly become unrepresentative for the current period, and the model that was performing well may now miss peaks by a full hour.
In this blog, we’ll show how basing forecasts on historically comparable periods leads to a more robust and interpretable forecasting strategy, especially during daylight-saving transitions when regions shift at different times.
Handling Daylight Changes in a Single Region
Consider a call centre that serves only customers from the European Union. This entire region moves from Central European Time (CET) to Central European Summer Time (CEST) on the same Sunday in late March. Although the total number of calls received per day tends to remain consistent, the intra-day pattern distribution of those calls shifts.
What happens: people start calling the call centre at 09:00 local time. For example, at first, this is also 09:00 UTC. After the clocks move forward for daylight saving time, 09:00 local time becomes 08:00 UTC.
What doesn’t change: people still start calling at 09:00 local time.
What appears to change (if your model works in UTC): the call suddenly seems to start an hour earlier. The morning peak, lunchtime dip, and afternoon surge all appear to shift one hour earlier in UTC.
Luckily, when everyone in your customer base changes clocks at the same moment, this is very easy to handle. You simply shift your forecast pattern by one hour. The shape of the curve, the highs and lows within the day, remains exactly the same; it’s just shifted by one hour to the left (or right, when moving back to standard time). This is why we can simply “slide” the forecast 1 hour in the same direction the day after daylight change, and then it’s like nothing happened.
An example, if you’re used to seeing a morning peak at 09:00 UTC, then after the daylight change, that peak will now show up at 08:00 UTC. The lunch dip that used to be at 13:00 is now at 12:00 UTC, and so on throughout the day. As long as all your customers are in one region, there’s nothing tricky about this. The model just needs to “slide” the whole pattern to account for the daylight-saving shift. As long as everyone shifts together, the adjustment is simple.
What changes when you serve two shifting regions?
Your call centre has a new client, and now handles both Europe and the United States. The U.S. and Europe do not switch their time zones on the same day. The U.S. changes to summer time two or three weeks before Europe, and “falls back” to winter time a week later. Suddenly, you don’t have just two clock changes to handle each year, but four.
In theory, if you know the exact split between U.S. and EU callers, you could still manage this with the sliding trick from above: simply shift the European part of your intra-day pattern when Europe changes clocks, and shift the U.S. part when the U.S. changes. For example, if you know that 60% of your calls come from Europe and 40% from the U.S., you would shift 60% of volume on the day that the EU changes, and shift the last 40% when the US also changes. When the second (U.S.) daylight change has occurred, the whole forecast (100%) is now shifted in the correct direction.
In practice, it’s rarely that simple. Most of the time, you don’t know exactly where each call is coming from; there’s no country flag attached to every call. As a result, you can’t tell what percentage of your total callers have switched to daylight saving time on any given date. Instead of a clean, one-hour shift, you’re left with a messy overlap of regions that are out of sync.
In short, once your callers come from different regions that transition at different times, the simple time-shifting approach stops working. Forecasting now requires either extra information about caller locations or more advanced modelling to account for these regional differences.
Aligned vs. Misaligned periods
The key to handling time zone shifts between regions is to divide the year into four distinct periods: two in which Europe and the US are aligned (both on winter time or both on summer time), and two periods where one region has changed but the other has not.
These 4 separate periods can be seen in the image above.
- Aligned periods – both regions are in winter-time or both in summer-time.
- Misaligned periods – one region has switched, and the other has not yet.
This distinction is important because the intra-day patterns present during an aligned period cannot be applied to a misaligned period, and vice versa. For example, when Europe and the US are aligned, both in winter time or both in summer time, your historical data shows European callers appearing at 09:00 UTC and American callers at 15:00 UTC.
But in a misaligned period (for instance, the two spring weeks when the US has moved to daylight saving time and Europe has not), Americans suddenly start calling an hour earlier, at 14:00 UTC, while the EU keeps calling at 09:00 UTC. If you feed an “aligned” pattern into that mis-aligned week, your forecast will be off by a full hour for every EU call: you’ll expect them at 15:00 UTC, yet they arrive at 14:00 UTC.
Borrowing last year’s (mis)aligned shape
How can we forecast these misaligned periods? We have two misaligned periods per year, and as we saw in the paragraph above, we cannot use the intra-day pattern of an aligned period on a misaligned period. The only representable data we have for these misaligned periods is the data from the same period from last year.
And this is exactly what we do. The key is to rely on historically comparable data from the same misaligned period in the previous year. This is the only historical period where we had the same situation, and thus, we base our intra-day pattern on this. Note that the two misaligned periods in spring and autumn are not interchangeable nor applicable to each other. In spring, the US switches to daylight saving time before the EU, while in autumn it’s the other way around, and the EU returns to standard time before the US.
What about aligned periods? How do we forecast those?
Aligned periods are longer periods, typically at least 3 months. When both regions have shifted and are now aligned, we gradually build up new representable data which reflects the current intra-day situation. In practice, the number of days of history we use is a configurable parameter, usually between 28 and 90 days, which determines the extent to which the model relies on recent data. This ‘power’ parameter determines the sturdiness of the pattern. The effective history grows over time until it reaches the chosen level: a longer history makes the pattern more stable, while a shorter history makes it more responsive to recent changes.
During these initial weeks, we refer back to the intra-day pattern from last year’s aligned period, which provides the closest match to the current situation. As days go by, and we collect enough fresh representable data, we can switch to using this more recent data as a basis for our intra-day pattern in the forecast.
In short, when sufficient recent history is not yet available, such as during misaligned periods or the first months of aligned periods, we rely on comparable historical periods from the previous year. Once enough current data becomes available, the forecast gradually transitions to incorporate the most relevant and up-to-date patterns.
Automating the switch in CCforecast
All in all, two main steps should be automated within the forecasting engine. First, we define the different (mis)aligned periods, which can be scheduled years in advance. Then, after both regions have transitioned to or from daylight saving time, we wait until enough recent, representative data is available. From this point on, the forecasting engine begins referencing this more recent behaviour.
At CCmath, we use our forecasting tool CCforecast, a sophisticated yet user-friendly solution, to manage this transition seamlessly, without requiring manual adjustments throughout the year. One script defines all the (mis)aligned periods. In contrast, a second script ensures the forecasting engine always looks back at the most relevant intra-day patterns, based on the availability of representative data.
A special case occurs in October-November, when the EU and US transitions are only one week apart. During this short overlap, we still refer to the corresponding period from the previous year. However, because there is only one week of historical data available, we cannot apply the usual method of averaging multiple weeks. Instead of copying last year’s pattern directly, which would lead to overfitting, we use a spline smoothing technique developed by CCmath to generalise the pattern and improve robustness.
Takeaways and Discussion
Several approaches to handling the daylight-saving change have been tested, each comparing different ways of selecting representative historical data to base the intra-day pattern on. The most accurate and robust results were achieved by matching the current situation to (recent) historically comparable periods, rather than relying only on recent data or overly complex strategies that added little value and made the system harder to maintain/understand.
The two charts below compare forecast performance in the first (aligned) week after both the US and EU have shifted to winter time.
- Image 1 shows the result when using only recent historical data. Notice how the forecast (orange line) consistently appears shifted to the left of the actuals (blue line). This is because the data used to create the intra-day patterns is from a period before the daylight change happened, when people started calling an hour earlier. The model hasn’t adjusted to the new timing yet, leading to a consistent mismatch.
- Image 2 shows the result when using historical data from the same aligned period last year. Here, the actuals and forecast overlap far better. There is no consistent one-hour offset between them, indicating that the model captured the shift in calling behaviour.
We also see this improvement reflected in the WAPE (Weighted Absolute Percentage Error). The WAPE is a good performance measure, but it is important to note that it depends on total volumes. A deviation of 10 units has a very different impact when the total volume is 100 compared to when it is 10,000. In this case, since the overall volumes remain the same and only the intraday pattern changes, WAPE is a good indicator of forecast alignment. The lower WAPE in the second image shows that using a historically comparable period, rather than relying solely on recent but mismatched data, more accurately captures the shift in calling behaviours.
Comparing these two images shows the importance of using historically comparable data during the first weeks/months of an aligned period. Once we have enough recent data which is representable for our current situation, the forecast can switch to using more up-to-date patterns with confidence.