The model does not know what day it is

A retrieved chunk says “the current limit is ten days.” Another says “the revised limit takes effect next quarter.” The user asks what the limit is now. Every word the model needs is in the prompt except the one the question turns on, which is today’s date.

Time is the piece of context that never arrives with the documents, and a model asked to reason about it without being told will simply invent a plausible present.

Two problems that look like one

The model doesn’t know the date. It has no clock and no request timestamp unless you supply one. Asked to assume, it leans on whatever period dominated its training data, which means it will confidently place “now” somewhere in the past.

Documents talk about time relatively. “Currently”, “as of last quarter”, “starting next month”, “the new policy”, “recently” — each is anchored to the moment the document was written, not the moment it is read. Resolving them requires the document’s date, which is a metadata problem, and then some subtraction, which is an arithmetic problem.

You have to fix both. Supplying today’s date to a model reading undated documents just gives it a more confident way to be wrong.

Put the date in the prompt

State it explicitly in the instruction block, in an unambiguous format:

Today's date is 2026-07-31. Use this as "now" when the question
or the sources refer to the present.

Three things to get right around that line.

Regenerate it per request. If your system prompt is a constant in a config file, or is being reused across requests to hit a prompt cache, the date freezes at whatever it was when the string was built. This failure is invisible for the first day and then permanent.

Decide whose clock. A system serving multiple regions has to pick between the server’s date, the user’s date and the corpus’s reporting calendar. Any of them is defensible; not choosing is not.

Don’t split it across places. A date in the system prompt and a timestamp in a chunk header, in different formats, is an invitation to pick the wrong one.

Resolving relative expressions in the sources

This needs the document’s date on the chunk. Without it the expression is unresolvable and the honest behaviour is to say so rather than guess — see assembling the prompt for why a date field is the single highest-value piece of chunk metadata.

With it, instruct explicitly:

Sources describe time relative to their own date. When a source
says "currently", "recently", "next quarter" or similar, resolve
it against that source's date and state the absolute date you
derived. If a source has no date, do not resolve its relative
time expressions — quote them and say the source is undated.

The requirement to state the derived date is what makes this checkable. “The limit rose to ten days in the 2026 update, effective from the third quarter” can be verified by a reader. “The limit is currently ten days” cannot be verified at all, because it doesn’t say what “currently” meant.

Three dates, not one

Most policy questions involve more than a publication date:

When the document was written. What its relative expressions are anchored to.

When the thing it describes takes effect. Often months later, and often stated only in prose inside the body rather than in any metadata field.

Today. Which determines whether the effective date has arrived.

An answer that conflates publication with effect is wrong in a way that reads perfectly: a document published in March describing a change effective in July, read in April, produces “the limit is ten days” when the true answer is “it will be ten days from July; today it is five.”

Instruct for the distinction and it mostly holds:

Distinguish when a source was written from when the rule it
describes takes effect. If a change is not yet in force as of
today's date, say what applies now and when it changes.

Not-yet-in-force is not a conflict

Two documents giving different limits because one supersedes the other is a conflict, and when sources disagree covers the handling. Two documents giving different limits because one describes a scheduled future change is not a conflict at all, and resolving it with a recency tiebreak produces the wrong answer confidently.

The distinguishing signal is an effective date in the body text, which a recency rule doesn’t look at. Worth an explicit instruction, because the default is to prefer the newer document and stop thinking.

Cheap checks worth having

Flag answers containing “currently”, “now”, “recently” or “at present” with no absolute date nearby. Almost always a resolvable expression that wasn’t resolved.

Flag retrieved chunks with no date field. A per-query count is a corpus-quality metric as much as an answer-quality one.

Flag a wide date spread across retrieved chunks. High correlation with superseded material in the context.

Test with a fixed date. If your evaluation harness passes a real clock into the prompt, yesterday’s passing answer can fail today for reasons unrelated to your change. Pin the date in tests, and keep one unpinned case to catch the frozen-system-prompt bug.

The default is a silent wrong guess

None of this is expensive; the reason it goes unnoticed is that the failure never announces itself. A model with no date does not ask for one. It picks a year, answers as though it were that year, cites real documents while doing it, and the answer looks exactly like a correct one.