Flow
Inputs and what the importer does
Each kind of timing input and the importer behavior it gets.
1Real date in the window
Used as the message time.
2Small time-since-launch number
Not used as a date; other fields are tried.
3End minus start, positive and modest
Kept as the tool call duration.
4End before start, or huge gap
Duration dropped.
5Chat with no usable time
Stamped with the moment it was read.
The editor I was reading chat history from puts a start and end number on each message. Sometimes they're real times. Sometimes they're just how long the app had been open.
I was teaching my agent-session dashboard to read that editor's saved chats. The code I added treats each timing number as one of two things, with nothing in the record to say which: milliseconds since 1970, or milliseconds since the app started. I haven't counted how often each one shows up.
Why the wrong kind doesn't blow up
A time-since-launch number is still a valid date. It's just the wrong one:
new Date(5_400_000) // 1:30 a.m. UTC, January 1st, 1970
No error. A chat from this week would start in 1970 and last fifty years. Charts would get an empty tail, and cleanup jobs would call it ancient.
The good news is size. Real dates today are huge numbers. Time since launch is much smaller. A range check can tell them apart.
A window of years
So the importer only treats the number as a date if it falls inside a window of years, from a few years before the code was written to a few years ahead. If it doesn't, it tries the message's other time fields in order. If none work, the message gets no time.
The ranking I'd question
The risky number is tried first, before the text fields that can't be misread. I'd guess that's because a real one is very precise. It's safe now, since an app would need to run for about fifty years to fool the window. But if the editor ever changed what that number counts from, the field the code trusts most would be the weakest.
The stopwatch still works
For tool calls, end minus start gives a duration. If both came from the same launch, the launch cancels out and the answer is right. The importer keeps it only if it's above zero and under a sensible ceiling. Otherwise it's dropped.
Conversation times are looser
A conversation's "last updated" time is just the last message the loop saw, which is only right if messages are in order. Using the earliest and latest message times would be safer. When there's no usable time at all, the importer uses the moment it read the chat, so old chats can look new.
Untested, and it expires
No test covers any of this yet. The window's top edge is a fixed year. Once we get there, every real time will fail the check and the importer will fall back to the other fields without saying so, and nothing will catch it.