Ask an AI what you signed in March and it will answer with total confidence. It will also be guessing. A language model has no clock, no calendar and no index of your files. A date in a document is just text to it, and "last Tuesday" points at nothing unless the prompt says what today is. That gap is why AI gets dates wrong on documents it can read perfectly.
This is not the knowledge cutoff problem. Cutoff is about what the model learned during training and when that training stopped. AI temporal reasoning is about dates sitting right in front of it, in your own contract, invoice, lab report or email thread. The model can read the date perfectly and still place it on the wrong point of the timeline.
The model has no clock unless someone gives it one
Nothing inside a language model knows what day it is. The weights were frozen at training time. Every sense of "now" a chatbot appears to have was injected into the conversation by the product wrapped around it, usually as a line in the system prompt.
Anthropic publishes the system prompts used by the Claude consumer apps, and they contain a currentDateTime template variable that gets substituted before the model ever sees your message. The same page states plainly that those system prompt updates do not apply to the Claude API. A developer calling the model directly, with no system prompt of their own, hands it no date at all. The chat app is doing the work, not the model.
Now put a relative date in front of that model. "The renewal is due next quarter." "We agreed this two weeks ago." Each one is an arrow with no origin. When the anchor is missing, the model does not stop and ask. It picks something plausible and carries on.
A useful mental model: a language model is a very well read person who has just woken up in a windowless room with your documents and no watch. It can read every date on the page. It cannot tell you which ones are in the past.
Why dates are genuinely hard, not just occasionally missed
A date is not a number, it is a scatter of tokens
Models do not see "2026-03-12". They see whatever pieces the tokenizer chops it into. A 2025 study named this the date fragmentation problem and measured it with a date fragmentation ratio, showing that a date like 20250312 can be split into fragments such as 202, 503 and 12, which cut straight across the year, month and day boundaries a human reads. Heavier fragmentation lines up with accuracy drops of up to 10 points on uncommon dates, meaning historical and futuristic ones. The paper also traced how models reassemble those fragments, and found no calendar module at work: where a human maps each component onto a schema (03 is March, 12 is the day, 2025 is the year), the models stitch fragments back together in a flexible, format-dependent order driven by statistical association.
There is no arithmetic unit behind those tokens. When a model tells you a contract has 47 days left, it is predicting the text of a calculation, not running one.
Order has to be reasoned out, and order is where models fall over
Google researchers built Test of Time, a synthetic benchmark that separates the two skills temporal questions actually need: understanding the semantics of time, and doing arithmetic on it. The facts are synthetic, so a model cannot fall back on memorised world knowledge. It tests how problem structure, size, question type and the order the facts arrive in change the answer.
The fact order result is the one worth internalising. Feed the same facts in a shuffled order and accuracy drops. Sort them by target entity and start time and it climbs back. In the paper's numbers, Claude 3 Sonnet went from 45.71 percent on shuffled facts to 73.57 percent on sorted facts, a gain of nearly 28 points from changing nothing but the order of the input. Gemini 1.5 Pro gained about 12 points on the same swap. The effect is not universal: GPT-4 moved less than 2 points. The authors summarise the pattern directly: performance is consistently lowest when facts are presented in a shuffled order and consistently highest when facts are sorted based on the target entity and start time.
That is the shape of every question about your own files. Your documents did not arrive sorted. They arrived as a folder, an inbox and a downloads directory, so you hand the model the shuffled condition every single time.
Duration arithmetic is the weakest skill of all
The arithmetic half of Test of Time splits into categories, and the spread between them is brutal. Timezone conversion questions scored between 74 and 90 percent across the models tested. Duration questions, the how long between these two dates kind, scored between 13.5 and 16 percent. When GPT-4 and Gemini 1.5 Pro got a duration question wrong, roughly 21 and 25 percent of those wrong answers landed within one day of the correct one, the signature of a model that is estimating rather than counting.
"How long do I have left on this notice period" is a duration question. So is "how many days between the signature and the deadline."
The eight ways AI gets your dates wrong
Eight failure modes show up when you point a model at real documents rather than a benchmark. Each one has a cause, and each one has a fix. The quietest is the last row: a model summarising a folder will report a January event as a March event, simply because March is the date printed on the page it read. Nothing in the output looks wrong. There is no hedging, no flag, no citation of which date it used.
| Date failure mode | Why it happens | How to prevent it |
|---|---|---|
| Relative dates (last Tuesday, next quarter) | No clock, so there is no anchor to measure from | State today's date in ISO form: "Today is 2026-07-09." |
| Document with no date | Nothing on the page to ground the answer, so the model fills the gap | Put the date in the filename and in a header line |
| Several dates in one file | Created, sent, effective, signed and due all look alike as text | Label each one, then ask: "What is the signature date?" |
| Ambiguous format (03/04/2026) | Day-first and month-first conventions split the world; the digits are identical | Use ISO 8601 (YYYY-MM-DD), or spell the month out |
| Timezone drift | Timestamps near midnight land on different calendar days per zone | Store UTC offsets, and name the zone in the question |
| Ordering events across files | Shuffled fact order measurably reduces accuracy | Sort the evidence chronologically, or use a system that keeps it sorted |
| Date arithmetic and durations | Token prediction is not calculation; duration is the weakest measured skill | Make the model use a code tool, or check the maths yourself |
| Write date confused with event date | Both are just dates in text, and the document's own date is the most salient | Ask the model to quote the exact date string it used and where it came from |
What the benchmarks actually measure
The research is consistent, and the numbers are worse than most people expect.
TimeQA, a NeurIPS 2021 dataset built by mining time-evolving facts from Wikidata and pairing them with the matching Wikipedia pages, is the early landmark. The best model the authors tested reached 46 percent accuracy against a human score of 87 percent. Their conclusion was that the models lacked consistent temporal reasoning ability, not that they lacked knowledge.
TempReason, from ACL 2023, split the problem into three levels: L1 is time to time reasoning (what year comes after 2020), L2 is time to event (which club was this player at in December 2010), and L3 is event to event (did this happen before or after that). Closed book, ChatGPT scored 6.5 percent exact match on L2 and 12 percent on L3. Given the relevant facts in context, the same model reached about 47.5 and 49.5 percent. That second number is the important one. Even when you hand the model the evidence, it still gets roughly half of the temporal questions wrong.
TempReason also probed a bias worth knowing about. On a simple year prediction task, the two smaller models it tested, a fine-tuned T5 and FLAN-T5, were measurably biased toward contemporary time ranges: their scores between 2000 and 2020 were far higher than for earlier years, and they degraded on both the past and the 2020 to 2040 future range. ChatGPT was not fooled by that particular task, scoring 99.6 exact match overall. The lesson is narrower than a blanket claim that models are bad at old dates: the further a date sits from the dense middle of the training distribution, the less you should assume about a smaller model's grip on it.
TRAM, from the Findings of ACL 2024, is the broadest sweep: ten datasets covering ordering, arithmetic, frequency, duration, typical time, ambiguity resolution, relation, temporal inference, causality and storytelling. GPT-4 was the strongest model at 84.4 percent average accuracy with five-shot chain of thought prompting, and the paper states it remains 12.9 percent behind human performance of 95.2 percent, by its own accounting across the full suite. A frontier model, prompted well, is still meaningfully behind a person on the thing that looks easiest.
TRAVELER, a 2025 benchmark of 3,300 questions, sorted temporal references into explicit (a stated date), implicit (relative to the moment of speaking, like "this month") and vague. Models handled explicit references over short event lists well. Performance on implicit references clearly deteriorated as the list of events grew, and vague references produced the lowest scores across every model tested. The vaguer and the more numerous your documents, the worse the answer.
Six defenses that hold up
- Give the model today's date. One line at the top of the prompt: "Today is 2026-07-09." This single habit removes the largest class of errors, because it turns every relative expression into a solvable one.
- Write dates in ISO 8601. YYYY-MM-DD is unambiguous in every country. 2026-03-04 cannot be misread. 03/04/2026 can.
- Put the date in the filename and in the first line of the document. invoice-2026-03-04-acme.pdf beats scan_007.pdf. Put the anchor in front of the model twice.
- Ask the model to quote the date it used. "Answer, then quote the exact date string you relied on and the sentence it came from." A model forced to cite its date contradicts itself visibly instead of invisibly.
- Force a tool for arithmetic. If the model can run code, tell it to compute date differences in code rather than in prose. Duration is the weakest category in the benchmarks, and a two line script solves it perfectly.
- Sort your evidence before you ask. Paste documents in chronological order and say so. In Test of Time, sorting the facts was worth double digit accuracy points for two of the three models tested, at zero cost.
A prompt template that covers most of it: "Today is 2026-07-09. Using only the documents below, answer the question. Use ISO 8601 for every date. For each date you rely on, quote the exact string and say which document it came from. If a document has no date, say so rather than inferring one. If the question needs date arithmetic, compute it step by step."
The deeper fix is dated capture, not better prompting
Here is what most guides get wrong. They stop at prompting. Every defense above is you doing the model's bookkeeping by hand, and hand bookkeeping does not scale. "What did I sign in March" is hard not because the model is stupid, but because the answer depends on metadata nobody captured in a queryable form: which document, which March, which date on the page, in whose timezone.
A memory layer changes the problem rather than the prompt. MemX timestamps what you capture at the moment you capture it, so a receipt saved in March carries a real March timestamp rather than a date the model has to reconstruct from pixels. The query then filters on an actual field instead of asking a language model to eyeball a folder. The timeline underneath the answer is data, not inference.
The honest framing: no memory layer makes a model good at temporal reasoning. What it does is shrink the amount of temporal reasoning the model has to do, by turning "guess when this happened" into "look up when this was saved." Retrieval you can verify beats reasoning you cannot.
The limits matter too. A capture timestamp tells you when a document entered your memory, which is not always when the event happened. A photo of a January prescription filed in March is a March record of a January event. The fix is the same in both worlds: capture the event date explicitly, in ISO form, and never make a model infer it.
Frequently asked questions
01Does ChatGPT or Claude know what today's date is?
The consumer apps do, because the product injects the date into the system prompt before your message reaches the model. The model itself does not. Anthropic's published system prompts include a currentDateTime variable, and the same page notes that those system prompts do not apply to the API, so a raw API call ships with no date unless the developer adds one.
02Why does AI get date calculations wrong when it can do algebra?
Because it is not calculating. It predicts the text of an answer, and dates are fragmented into tokens that cut across year, month and day boundaries. In Google's Test of Time benchmark, duration questions of the how many days between these dates kind scored between 13.5 and 16 percent across leading models, far below their scores on other temporal tasks. The reliable fix is to make the model use a code tool.
03Is this the same as the knowledge cutoff problem?
No. Knowledge cutoff is about the recency of what a model learned during training, which is why it may not know about last month's news. This is a reasoning failure over dates the model can see perfectly well, in documents you handed it. A model with a cutoff of yesterday would still misread 03/04/2026.
04What date format should I use so AI does not misread it?
ISO 8601, meaning YYYY-MM-DD, for example 2026-03-04. All-numeric slash formats are genuinely ambiguous across regions: 01/11/06 can be read as 1 November 2006, January 11 2006 or 2001 November 6, depending on the convention. Spelling the month out is the next best option.
05How do I make AI build a reliable timeline from my documents?
Give it today's date, convert every date to ISO 8601, sort the documents chronologically before you paste them, ask it to quote the exact date string it used for each event, and have it compute any durations with a tool. Sorting alone is worth a large accuracy gain: in Test of Time, sorted facts beat shuffled facts by up to roughly 28 percentage points for one model.
Temporal reasoning is the failure mode that hides best, because a wrong date looks exactly like a right one. The defense is not to trust the model less in general, it is to stop asking it to infer facts that could have been recorded. Anchor the prompt with today's date, write dates in ISO, and keep timestamps on the things you save. Then "what did I sign in March" has an answer instead of an estimate.
