No Sense of Now: The Temporal Blind Spot in Frontier AI

On New Year's Eve I ran a livestream celebrating every country's entrance into 2026. Frontier models helped me build the whole experience—countdown overlays, timers, celebration triggers, the lot. And for hours it was flawless. Auckland, Sydney, Tokyo, Berlin, Paris—every rollover fired right on cue.

Then midnight hit London. The moment my own country crossed into 2026, the clock stopped dead and the overlay proudly announced the next celebration was in 364 days. The code never accounted for 2026 becoming today at midnight—the second we fell into the new year, the shabby outdated countdown logic decided the party had already happened and started counting towards the next one. Overall L + ratio for the frontier models that helped me build it, and a swift apology to everyone left waiting for the England fireworks to kick off on my stream.

It's a funny failure. It's also the perfect miniature of a much bigger problem I keep hitting in serious work: modern LLMs have no sense of time. Not "slightly fuzzy about dates". None.

Ole' Reliable Syndrome

I first clocked this working through issues in codebases I've been developing. My agents kept reaching for the lazy, easy, old option. I initially wrote it off as a training data issue, or maybe a sensible reluctance to lean on newer tech that might break the stack. Then I started working in environments built on torch, transformers and friends—exactly the sort of libraries you'd expect a cutting-edge model to either know cold from its latest training run or go and look up. Nope. Straight default to ole' reliable, every time.

• Whisper transcription: the models always feed me older Whisper models. They know the structure exists, but they clearly don't track recent releases closely.
• Fresh torch environments: often not set up with CUDA in mind, even on CUDA-capable hardware, because the model is hedging against torch compatibility it can't verify.
• Transformers: the library moves so fast that anything not directly tied to the specific version your project pins needs documentation fed in, or you're in hallucination territory.

So I had to start actively driving my agents to seek out answers instead of leaning on what they "know". And here's the dangerous bit: as my own understanding of the newer code progressed past theirs, asking an agent to do something it doesn't know is possible—without a search—is a recipe for massive hallucination. It won't say "that API is after my time". It'll invent one.

There Is No Now

The root of it: no matter how much you tell a model that now is now, in its mind now is its training cutoff. It doesn't count the days between. It doesn't know it was trained six months ago unless you tell it—that information isn't secretly fed in anywhere. Every conversation starts at the same frozen moment, and the model has no idea how far the world has drifted since.

Try this framing: a new law passes after the model's training, and it can't be searched for. You tell the model about it. Congratulations—you are now the only voice of reason in the room. The entirety of that workload lives on your shoulders, not the model's. It can't weigh your one message against a world of training data that says otherwise, because it doesn't know its world is old.

"A model doesn't know what it doesn't know yet. The clock between its cutoff and your deadline runs on you."

Stateless by Design

Why does this happen? Because models are stateless. There's no state that tells them "this is the wall clock, hours, minutes, seconds" to balance their knowledge against. So a model can't know how far out of date it is relative to the code it's working on—and it gets worse, because chunks of the training batch were already a year stale on the way in. The cutoff isn't even an honest timestamp; it's the newest edge of a dataset that stretches years backwards.

Documentation in coding-adjacent fields needs a backup plan for this—a way to restore a model's memory about an update. But you can't restore something that was never there. What's actually needed is versioning that's legible to the model's reasoning at inference time: knowledge that carries its own age, so the model can treat it with appropriate suspicion. And that is a different beast entirely from anything we're shipping today.

Under the Hood: Why the Machine Can't Feel Time

For the technically inclined, here's what that statelessness is actually made of.

A transformer processes your entire prompt as one static window of tokens, and self-attention relates every token to every other token in that window. Positional encodings tell the model where a token sits relative to its neighbours—but that's geometry, not chronology. It's order within the text, nothing more. There is no native dimension in the architecture for real-world time passing outside the string. "Today" is just another token, and its meaning was frozen the day the weights were.

Researchers have taken swings at this—stamping training data with time tokens so the model learns that facts carry dates. It helps in a narrow benchmark sense; the model gets better at reciting when something was true.

What it doesn't do is scale into actual temporal reasoning at runtime. It cannot dynamically work out how an event after its cutoff rewrites the framework it learned, like my new-law example above. Knowing a fact's timestamp and reasoning across time are completely different capabilities—and the second one is still an open architectural problem, not a fine-tune away.

Which is why the fix has to live outside the model for now. The architecture can't feel time; the systems wrapped around it have to feel it on the model's behalf.

What I Actually Do: Guided Documentation Discovery

My working fix is what I'd call guided documentation discovery. If I'm building something that needs the latest packages, I present links to the current documentation to the models before the task starts—front-loading context so the model is reasoning from today's reality rather than its own frozen snapshot.

The mindset shift is simple: treat model knowledge as stale-by-default for anything that moves fast. The model is a brilliant reasoner with an out-of-date library card. Your job is to hand it this month's edition before it starts quoting last year's.

Who's at Fault When the Vault Gets Built on Lies?

Here's my actual opinion, since that's what this post is: I blame developers. Us. For not noticing sooner and not taking it seriously enough now. This isn't an unsolvable physics problem—there are genuine systems that can be built external to the model to solve it. Some have tried with RAG, and fair play, but RAG is only half the picture. Retrieval tells a model what's in the documents; it still doesn't tell the model that its own instincts are eighteen months old and should lose every argument with the retrieved text.

The community needs to work together and work harder on this instead of hand-waving it like it's someone else's job. Every codebase, every workflow, every countdown clock built on a model's frozen sense of time is a vault built on lies—confident, fluent, well-formatted lies about a world that's already moved on. And when the vault cracks, who's at fault? The model that can't know better, or the builders who do?

My stream's fireworks were 364 days late. Yours might be something that matters. Front-load the docs, pin your versions, and stop assuming the model knows what year it is.

Been bitten by a model living in the past? Come tell me about it on Discord—especially if you're building tooling that takes a real swing at the problem.

---

Share: Twitter · LinkedIn