On the Encoding of Calendar Features in Covariate-Informed Time Series Foundation Models

Introduction to the show: ident: AI Radio. Generated commentary on the latest Artificial Intelligence papers.

Tom: Today's paper: "On the Encoding of Calendar Features in Covariate-Informed Time Series Foundation Models".

Jane: The gist The way information is propagated into the model substantially affects forecast accuracy of TSFMs.

Tom: First, who's behind it and why it matters.

Title and authors: Tom: So we're looking at this paper today, "On the Encoding of Calendar Features in Covariate-Informed Time Series Foundation Models," and it really gets to the core issue of how we feed calendar information into these time series foundation models.

Jane: Right, Tom, it seems like they are pointing out that just throwing calendar data into a model isn't enough; the way you encode that data is actually what makes a big difference in how accurate those forecasts end up being.

Lu: Exactly. They systematically compare seven different ways to encode calendar information across four top time series foundation models, and it shows that this choice has a substantial impact on forecast accuracy.

Meng: So, are we talking about specific ways to represent days of the week or holidays into the model's input data? Because when I'm trying to deploy something at scale, I need to know if those representation choices will cause problems later on.

Tom: They are comparing seven different encoding strategies across four models: Chronos-two TabPFN-TS-three TiRex-two and TimesFM-three <ref:2610.13676#pg1,Chronos-2, TabPFN-TS-3, TiRex-2>. The results show that the way information flows into the model really affects its forecast accuracy.

Jane: And they found some pretty big differences in performance; they mentioned MASE differences of up to nine point nine percent on nonholidays and eighty three percent on holidays within a single model. That's a huge gap, Tom.

Lu: What’s interesting is that the effectiveness of these encodings isn't the same for every model; it’s model-specific, which suggests that what works best depends entirely on the architecture you're using.

Meng: That sounds complicated to manage in production. If Chronos-two needs one specific encoding to work well, but TabPFN-TS-three needs a totally different one, that complicates our pipeline a lot <ref:2610.13676#pg1>.

Tom: It does, but it also tells us where the model's sensitivity lies; for instance, Chronos-two benefits most from two separate target encodings: ThW and ThH encoding <ref:2610.13676#pg1>.

Jane: That’s fascinating—so the paper is showing us that we need to tailor our representation based on what the specific foundation model is designed to learn.

Title and authors: Lu: And they also noted that TabPFN-TS-three was the only model that improved under all seven encodings and in all three window types, which tells us something about its inherent flexibility <ref:2610.13676#pg1>.

Meng: I wonder if that flexibility translates well when we try to use these models on real, messy data where the patterns aren't perfectly clean.

Tom: Moving into how they figured out *why* things work, they used SHAP analysis to look at the contribution of these covariates relative to the autoregressive part of the model.

Jane: That’s a smart way to look at it; SHAP helps explain why some combinations degrade performance by showing exactly what each encoding is summarizing.

Lu: On holidays specifically, all models assign substantially greater importance to those calendar features than they do on non-holidays, which makes sense since the paper notes that target encodings clearly outperform conventional ones when dealing with those irregular holiday patterns.

Meng: So for a deployment scenario where we care most about holidays—like predicting sales around Christmas or New Year's—we should probably focus our encoding choice there first.

Tom: And on non-holidays, Chronos-two actually seems less influenced by either of the two specific encodings they tested compared to the other models <ref:2610.13676#pg1>.

Jane: So the implication for us is that if we are forecasting something where holidays are a major factor, we should probably lean into those target encodings instead of just using standard one-hot or cyclic methods.

Lu: The paper suggests that current benchmarks might be flawed because they test everything under a single fixed encoding, which could be conflating the model's actual capability with the encoding choice itself.

Meng: That means we can't just pick a benchmark and assume it represents the best possible setup for our production system.

Tom: They suggest that future benchmarking might need to include multiple encoding strategies as an explicit factor, or perhaps model developers should integrate this kind of model-specific categorical feature handling directly into the model design itself.

Title and authors: Jane: That would be a big shift in how we think about evaluating time series foundation models going forward.

Lu: And for future work, they point toward a data-driven approach, like in-context clustering, where you identify time series specific characteristics from the context and use those to derive or select suitable encodings.

Meng: That sounds promising because it moves away from us having to manually test seven fixed encodings every time we get a new dataset.

Tom: It's about moving toward an adaptive system where the encoding is selected based on the data it's seeing, rather than just a pre-set rule.

Jane: So, to wrap up this discussion on "On the Encoding of Calendar Features in Covariate-Informed Time Series Foundation Models," it really highlights that how we represent time and calendar signals matters a lot for forecast accuracy across all models.

Lu: The main implication is that encoding is not just an implementation detail; it’s a critical design choice that needs careful study when building these large models.

Meng: From an engineering standpoint, this means we have to be much more deliberate about feature representation when we move from research to deploying these kinds of systems.

Tom: Exactly. We need to consider the model-specific nature of those encodings, especially when dealing with those big performance swings between nonholidays and holidays.

Jane: So as we look ahead, we should probably keep an eye on how they explore using target-based methods like ThH encoding for situations where holidays are a significant part of the series.

Lu: That seems like a solid direction because it directly addresses the biggest performance gap they found in their comparison.

Meng: I just hope that when this gets integrated into real production systems, the overhead of figuring out which encoding to use doesn't become too much of an issue at scale.

Tom: Yeah, that’s the practical hurdle we need to keep in mind as we build these things.

Jane: We'll be right back after a short break with more papers from arXiv.

The paper's summary: Jane: So, to recap, this paper is looking at how we feed calendar information—like holidays or weekends—into big time series foundation models and finding out that the way you encode that data really changes how good the forecast gets across all these different models.

Tom: Right. It’s not just about having a calendar feature in there; it’s about which specific representation, whether it's ordinal or one-hot, or even target encoding, you use to describe those calendar days.

Lu: Exactly. They compared seven different encoding strategies across four top models—Chronos-two TabPFN-TS-three TiRex-two and TimesFM-three—and the results show that this choice matters a lot depending on the model you’re using.

Meng: So what does that actually mean for deployment? Does it mean we have to rewrite our entire data pipeline just because we switch from one foundation model to another?

Jane: Not necessarily, but it means we can't just use a single fixed way of encoding for everything. The paper found that some models are super sensitive; Chronos-two for example, really benefits from a specific two-part encoding—the ThW and ThH format.

Tom: That’s interesting because it tells us the model architecture dictates the best input structure. And they saw this clearly in how TabPFN-TS-three performed; it was the only one that kept getting better no matter which of those seven encodings they tested.

Lu: So, when you look at why some combinations are bad, they used SHAP analysis to figure out exactly what each encoding is summarizing relative to the model’s core prediction part. It shows how some representations actually dilute the signal for certain architectures.

Jane: And one of the biggest numbers they got was about holidays. The performance gap between the best and worst encoding within a single model on holidays was huge, up to eighty-three percent difference in MASE score for TiRex-two.

Tom: That eighty-three percent is massive; that’s a huge penalty if you pick the wrong representation when you need holiday accuracy. It really drives home why target encodings, which focus on what the future target actually looks like, seem much stronger in those specific scenarios.

Meng: If we’re shipping models to production, knowing that a single encoding could cause an eighty-three percent drop in performance for a specific use case is something I need to worry about when selecting our baseline setup.

Lu: The paper suggests that future benchmarking needs to change because right now, benchmarks fix the encoding. They argue we should probably test models using multiple different encodings as a factor themselves, or developers should build in this kind of model-specific handling directly.

Jane: That points toward a big shift in how we evaluate these things; it’s moving away from just comparing model A versus model B to comparing Model A with Encoding one versus Model A with Encoding two.

Tom: It means that simply picking the highest score on one standard benchmark might be misleading if the encoding used there isn't right for your actual data distribution.

Lu: And they also look ahead, suggesting we should try something data-driven, like in-context clustering to see what time series specific characteristics naturally emerge from the context and use those to pick the best encoding automatically.

Jane: So the next step is moving from fixed rules to adaptive representations that learn the best way to encode things based on what the data actually looks like.

The paper's improvements: Tom: So, they aren't just stopping at finding out which encoding is better; they’re proposing how we should actually *use* that information to build better AI systems for forecasting.

Jane: Right, so beyond just picking a good input format, they suggest we need a more flexible system. They want to move toward an adaptive approach where the encoding isn't fixed but is chosen based on what the data itself looks like.

Lu: They’re talking about this idea of in-context clustering; basically, identifying time series specific characteristics from the input context and then using those characteristics to derive or select a suitable encoding automatically.

Meng: That sounds complicated to build into a production pipeline, but if it actually makes the model more robust across different datasets, I see the value. What does that mean for running costs?

Tom: It means we might reduce the manual effort of testing seven different fixed encodings every time we get new data because the system would figure out which encoding works best for that specific series on its own.

Jane: It changes how we think about feature engineering; instead of us deciding on a strategy beforehand, the AI should be able to discover what representation it needs to perform optimally.

Lu: They also emphasize using SHAP analysis more deeply to understand the model’s internal logic. The idea is that we need better tools to quantify exactly why certain encoding choices cause performance drops for specific model types.

Tom: That would give us a much clearer picture of the failure modes in different architectures, which is crucial because we can't afford to waste time tuning something that isn't actually helping.

Jane: It’s about gaining a deeper understanding of the relationship between the representation, like our calendar encoding, and what the model is actually learning from it.

Meng: If we can pinpoint exactly where the signal gets lost when we choose a poor encoding, we can stop guessing and start fixing those specific weaknesses in our deployment strategy.

Lu: They are pushing for a move toward fully data-driven selection for those encodings, which is a big step away from manual heuristic choices.

Tom: I think that’s where the real engineering potential lies; moving the decision-making process from us to the data context itself.

Jane: So, we’re looking at a future where the AI decides how to best represent time and calendar information on its own for each specific task.

Conclusion: Tom: So we’re wrapping up on "On the Encoding of Calendar Features in Covariate-Informed Time Series Foundation Models," and to sum it up, the core message is that how you encode calendar data isn't just a minor tweak; it has a massive, model-specific impact on forecast accuracy.

Jane: Exactly. It shows that fixing a single encoding strategy for all models is going to hurt your performance if you’re dealing with complex data where holidays matter.

Lu: The implication for the field is clear: we need to stop treating encoding as a one-size-fits-all input and start thinking about how the representation should adapt based on what the model needs.

Meng: From a production standpoint, that means we have to design our systems to handle this variability, or they’re going to break when we move from testing data to real traffic where those calendar effects are messy.

Tom: I agree. We can’t just ship a model and hope it works because the encoding happened to be decent for that one dataset you tested on.

Jane: It pushes us toward more nuanced benchmarking, where we have to evaluate models using different encoding strategies as an explicit part of the test setup, not just one fixed setting.

Lu: And they are looking toward data-driven methods like in-context clustering to help derive those best encodings dynamically, which is a much more scalable idea than us manually picking them.

Meng: If that data-driven approach works reliably at scale and doesn't introduce massive overhead, I’m open to exploring that path. The challenge is always making sure the inference cost stays low.

Tom: Yeah, the engineering reality is always about balancing accuracy gains against computational complexity, so if a new encoding strategy gives you a big lift but doubles your computation time, we have to weigh that carefully.

Jane: It sounds like we’re moving toward systems that are more flexible and less reliant on hand-picked rules for everything.

Lu: The authors flag their limitation, though: all these experiments were restricted to settings where the target followed calendar effects like holidays and weekends, so it doesn't directly apply to time series where those patterns aren't dominant.

Meng: That makes sense; if the paper only works when holidays are a big part of the signal, then applying it elsewhere isn't guaranteed to give you that same huge accuracy boost.

Tom: So, for now, we see this as a strong foundation showing exactly why encoding matters when dealing with time-aware data.

Jane: It’s a solid piece of work on how to make these models smarter about the context they’re reading.

Lu: Anyway, next week we’ll be looking at something completely different—we're diving into how embedding bias shows up in conditional independence testing for LLMs.