Expose message timestamps to the model (with safeguards) for better temporal reasoning

[clear forge]

Hi 👋

I’d like to suggest a feature that would significantly improve ChatGPT’s reasoning quality and coherence in longer conversations.

Currently, the model only sees the order of messages, not their timestamps. This leads to incorrect temporal inferences, for example:

• assuming something took “45 minutes” when it actually took 2 hours,
• using phrases like “earlier today” or “just now” incorrectly,
• losing track of pacing in coaching, planning, journaling, or multi-hour conversations.

Suggestion:
Expose message timestamps to the model, or at least make them optionally available, so it can reason about actual time gaps between turns.

To address privacy / safety concerns, this could be done with safeguards, for example:

• make it opt-in per user or per conversation,
• expose timestamps only internally to the model (not visible in UI),
• allow coarse-grained timestamps (minute-level or rounded),
• or allow users to choose between full timestamps and relative time deltas.

This would:

• improve temporal accuracy and coherence,
• reduce incorrect assumptions about duration and pacing,
• enable better use cases in productivity, coaching, and behavioral tracking.

I think this would be a small change with a large positive impact on model quality and user trust.

Thanks for considering it 🙏

[sleek storm]

👍

[earnest burrow]

I like the general idea. I'm in favor! 😃👍🏻

[valid oak]

Why not just tell the model to time stamp it's responses? I just tried:

Going forward I would like you to time stamp each of your responses.

And that seemed to work.

[clear forge]

Good point — I honestly hadn’t thought about explicitly asking the model to timestamp messages, so thanks for mentioning it 🙂

That said, my request is less about my own convenience and more about giving the model a reliable notion of time.

If timestamps are only added because the user asks for them, then:

• they won’t exist in older parts of the conversation,
• they can be inconsistent or forgotten,
• and the model still won’t be able to reason about timing unless the user manually manages it.

What I’m really interested in is enabling the model to reason over time, for example:

• noticing that there is a 2-hour gap between technical messages and inferring that there was likely a lot of trial-and-error or an external action,
• or noticing that there are 3 days between two conversational turns and interpreting the evolution of a social situation differently than if it was 5 minutes.

So yes — user-side timestamps can help, but model-side access to timestamps would allow the system to:

• maintain temporal coherence,
• reason about pacing and evolution,
• and avoid incorrect assumptions about duration and recency.

Whether or not this is easy to implement is of course another question — but conceptually, that’s the capability I’m trying to suggest 🙂

That’s why I’m framing this as a model capability rather than just a user workflow.

[signal ridge]

This is a solid description of the problem.

One thing I've been circling around while considering and documenting this feature suggestion in various communities is whether the model actually needs full timestamps at all vs. just knowing how much time has elapsed between turns.

From a reasoning standpoint, most of the failure modes you're describing ("earlier today", "just now", pacing problems, etc.) come from the model assuming no time has passed between turns unless explicitly told otherwise.

A minimal, opt-in alternative could be exposing a single derived value like "elapsed time since last user message" (e.g., milliseconds or seconds), rather than absolute timestamps. That keeps the feature in context, avoids time zone and privacy concerns, and still lets the model reason about whether it's been seconds, hours, or days.

Full timestamps might still make sense in some cases and I've seen that the message timestamps are available in the metadata, but I've become increasingly convinced that an elapsed-only variant could solve most of the coherence issues with far fewer "downsides" for anyone - including the OpenAI Development team.

Curious if others here have hit similar roadblocks or problems in long-running or asynchronous conversations.

[signal ridge]

My experience with this has been mixed. Because the model doesn't seem to have direct access to the actual timestamps of each turn - even internally - it has a tendency to introduce drift in the timestamp it logs. While that may be okay in certain time-insensitive conversations, other things like diagnostic troubleshooting or personal journaling can be adversely affected by imprecise time references.