I accidentally built a time machine.
A dental clinic wanted a voice AI to book appointments. The flow was simple. Call patients, offer slots, book the appointment, send confirmation. I built it, tested with ten sample bookings, everything worked. We deployed on a Monday.
By Tuesday morning, everything broke.
The Disaster
The receptionist called me in full panic. Forty seven patients were showing up, claiming they had appointments. The clinic had only eight scheduled. When she checked the system, every one of those appointments was marked as yesterday.
Yesterday.
I opened the logs, and my stomach dropped.
What the AI Was Saying
The conversations sounded perfectly normal.
The AI offered slots like tomorrow at 2 PM, Thursday at 10 AM, or Friday at 3 PM. Patients chose a slot. The AI confirmed it. The SMS confirmation went out with a date and time that looked correct.
The problem was hidden in what “tomorrow” meant.
Why This Happened
My prompt handled relative time. Tomorrow meant the next day. Thursday meant the upcoming Thursday. But I never defined the reference point.
Tomorrow relative to when?
The AI handled the conversation, queued the booking, and only later converted the relative time into an actual date. Because processing was asynchronous, the system clock had moved forward by the time conversion happened.
Tomorrow from the conversation was not the same as tomorrow from the processor.
Time zones made it worse.
The Actual Technical Failure
The call happened Monday afternoon. The patient said tomorrow at 2 PM. The AI logged “tomorrow at 2 PM” and queued it.
The booking processor ran late at night. It calculated tomorrow relative to that moment, not the call. The confirmation was sent the next morning. By then, the stored date already looked like yesterday in the logs.
Patients showed up confident. The system showed expired appointments.
How Bad It Got
This Thursday became last Thursday. Next week Tuesday became two weeks later. Tomorrow morning booked itself into the wrong day if the call crossed midnight.
One call happened at 11:45 PM. Processing happened at 12:05 AM. Tomorrow collapsed into today. The patient showed up two days off from what they expected.
It was a perfect storm of relative language, async processing, and time zones.
My First Failed Fix
I tried a simple rule. When the patient says tomorrow, add one day.
That made things worse.
A call at 11 PM plus one day still landed on the same calendar date depending on how the system interpreted it. At midnight, tomorrow became today again. Patients arrived nearly a full day early.
The Real Solution: Temporal Anchoring
The fix was to stop letting time float.
The moment a conversation starts, the system captures a timestamp. That timestamp becomes the anchor for everything. All relative language is resolved immediately against that anchor and never recalculated again.
Tomorrow is converted once. Thursday is resolved once. The result is locked.
The database never stores relative time. Only absolute timestamps with timezone information.
How the New System Works
When a call begins, the system records the exact date, time, and timezone. When the patient says tomorrow at 2 PM, the AI immediately converts it into a full absolute datetime based on that anchor.
Before booking, the AI confirms using a full date. Not tomorrow. Not next week. Tuesday, January 14th at 2 PM.
Once confirmed, the system stores only the absolute timestamp. Processing delays no longer matter.
The Transformation
The same call now behaves predictably. A Monday call for tomorrow always becomes Tuesday, regardless of when background processing runs. Midnight calls behave correctly. Time zones are clarified before booking.
Patients show up on the right day. Receptionists stop panicking.
Edge Cases That Mattered
Same day bookings are validated to ensure the time hasn’t already passed. Midnight calls are anchored to the previous day. Ambiguous phrases like this Friday are clarified explicitly. Dates without years are confirmed. Different time zones are handled by asking before booking.
Every ambiguity is resolved before anything is stored.
The Results
Before the fix, dozens of appointments were wrong within days. Patients were angry. Staff lost trust. Manual cleanup consumed hours.
After the fix, wrong date bookings dropped to zero. Complaints disappeared. Trust came back.
What I Learned
Relative time is dangerous. Language about time shifts depending on context and moment.
Everything must be anchored. Relative expressions should be converted immediately, never later.
Full dates prevent confusion. Tomorrow is vague. Tuesday, January 14th is not.
Time zones must be explicit. Midnight must be tested. Async systems must never reinterpret time.
The Principle
Time is absolute. Language about time is relative. Convert immediately and confirm explicitly.
Because tomorrow means something different to everyone.
Your Turn
Have you ever chased a time related bug that only appeared at midnight? How do you handle relative time in conversational systems? What safeguards do you use in scheduling automation?
Written by FARHAN HABIB FARAZ
Senior Prompt Engineer and Team Lead at PowerInAI
Building AI that knows what tomorrow actually means
Tags: scheduling, timemanagement, voiceai, automation, timezone, promptengineering
Top comments (0)