A user asks the assistant
to book the review
for next Friday.
It books a Friday.
A Friday that was already over
before your product launched.
Nothing crashed.
The tool call was well formed.
The date was a real date.
It was simply not
anywhere near now.
A model has no clock.
It has a sense of time
made of everything it read,
and everything it read
stopped on some day
that is now behind you.
Ask it what day it is
and it will not say
that it cannot know.
It will guess,
fluently,
somewhere close to the end
of its training data,
and every relative phrase
gets resolved against that guess.
Next Friday.
End of the quarter.
Last month's numbers.
Anything due in thirty days.
It is the same with versions.
Ask for the latest release
of a library
and you get the latest one
the model has heard of,
stated as present fact.
Ask how old a person is,
how long until a contract ends,
whether a certificate has expired,
and the arithmetic is fine.
It is the starting point
that is wrong.
So give it the starting point.
Put the current date,
the time,
and the user's time zone
into every request,
from your server's clock,
not from the user's text
and not from a cached prompt
written on the day you deployed.
Then go further,
because a model that knows the date
can still count badly.
Do not let it turn
next Friday
into a date.
Let it pass the phrase
to a function of yours,
which works out the date
the way the rest of your code does,
in the right zone,
with a test.
Show the resolved date
back to the person
before anything is booked.
Friday the ninth.
Right?
And anything that changes,
versions, prices, deadlines,
fetch it.
Do not ask the model to remember it.
A model is fluent about time
the way a postcard is fluent
about the weather.
It describes the day it was written.
Tell it what day it is today.
– Serguey Asael Shinder
Top comments (0)