Description
When the timestamp feature is enabled, the current date/time is delivered to the model as a synthetic tool-call pair appended after the latest user message — an internal_timeawareness_current_timestamp call followed by its result.
Observed behavior (GLM 5.2): every synthetic tool result contained 2026-09-04T14:33:08+00:00, yet the model consistently reported 2025-09-04 in all responses. When the user pointed out the discrepancy, the model began confabulating — fabricating claims about tool calls it had never made and mixing up results across multiple tools — apparently unable to reconcile the injected result with what it was asserting.
The timestamp injection mechanism itself is working correctly: the tool result with the right year was present in every turn's context.
Hypotheses (none confirmed)
- Training-year prior. The model may treat its training-data year as more authoritative than the tool result.
- Injection ordering. Colleagues have flagged that the position of the synthetic pair in the message sequence may differ from what some models expect as standard, potentially breaking GLM's reasoning about tool results. This is unconfirmed and worth verifying separately.
- Formatting or attention issue. The model may fail to attend to the tool result for unrelated reasons (context length, content format, etc.).
Suggested investigation
- Verify whether the issue reproduces with other models
- Audit the exact message ordering delivered to the LLM when the synthetic pair is injected and confirm it matches the model's expected tool-call flow
- Check whether adding an explicit current-date annotation to the system prompt (alongside the existing synthetic injection) resolves or mitigates the behavior
_TimestampAnnotationTransformer annotates non-synthetic tool results but explicitly skips synthetic timestamp messages and does not inject anything into the system prompt — this gap may be worth addressing regardless of root cause
Description
When the
timestampfeature is enabled, the current date/time is delivered to the model as a synthetic tool-call pair appended after the latest user message — aninternal_timeawareness_current_timestampcall followed by its result.Observed behavior (GLM 5.2): every synthetic tool result contained
2026-09-04T14:33:08+00:00, yet the model consistently reported2025-09-04in all responses. When the user pointed out the discrepancy, the model began confabulating — fabricating claims about tool calls it had never made and mixing up results across multiple tools — apparently unable to reconcile the injected result with what it was asserting.The timestamp injection mechanism itself is working correctly: the tool result with the right year was present in every turn's context.
Hypotheses (none confirmed)
Suggested investigation
_TimestampAnnotationTransformerannotates non-synthetic tool results but explicitly skips synthetic timestamp messages and does not inject anything into the system prompt — this gap may be worth addressing regardless of root cause