Summary
Follow-up to #76. The conversation-test server (POST /api/v1/agents/test/messages) honors override_timestamp only when it is a timezone-naive ISO 8601 string (e.g. 2030-12-25T09:30:00, interpreted in the agent's timezone). Offset (-07:00), Z, space-separated, and invalid values are silently dropped — the agent falls back to the real wall clock with HTTP 200, no error (TestMessage.override_timestamp is typed anyOf[string,null] with no date-time format, so there is no schema-level validation).
#76 corrects the docs/example/help/test to steer users to the honored form. This issue tracks making the CLI fail loudly instead of silently when a non-honored form is passed, so the flag's purpose (deterministic date-sensitive tests) can't be quietly defeated by a typo or a timezone-aware value.
Proposed behavior
Client-side warning to stderr (non-breaking — still sends) when --override-timestamp is non-empty and carries a confirmed-ignored signal:
- a trailing
Z,
- a
±HH:MM timezone offset after the time,
- a space separator instead of
T.
e.g. warning: --override-timestamp "...Z" carries a timezone; the server only honors timezone-naive ISO 8601 (e.g. 2030-12-25T09:30:00) and will silently ignore this, falling back to the real clock.
Design notes / open questions
- Negative check, not positive validator. Only
YYYY-MM-DDTHH:MM:SS is confirmed honored; whether fractional-seconds or seconds-less forms are honored is unknown, so a positive "warn unless it matches X" risks false positives. Warn only on the confirmed-bad signals above. (Tradeoff: a negative check won't catch pure garbage like not-a-real-timestamp, which also silently no-ops.)
- Warn, don't hard-error. A hard rejection breaks the thin-passthrough contract and would become actively wrong once the server is fixed.
- Keep it trivially removable. Per ZOO-7814 the server should soon accept tz-aware ISO 8601 (or return a 422 instead of silently falling back). When that lands, relax/remove this guard.
- Behavior under
--output json / scripting: warning goes to stderr so it shouldn't corrupt stdout — confirm that's acceptable.
Related
Summary
Follow-up to #76. The conversation-test server (
POST /api/v1/agents/test/messages) honorsoverride_timestamponly when it is a timezone-naive ISO 8601 string (e.g.2030-12-25T09:30:00, interpreted in the agent's timezone). Offset (-07:00),Z, space-separated, and invalid values are silently dropped — the agent falls back to the real wall clock with HTTP 200, no error (TestMessage.override_timestampis typedanyOf[string,null]with nodate-timeformat, so there is no schema-level validation).#76 corrects the docs/example/help/test to steer users to the honored form. This issue tracks making the CLI fail loudly instead of silently when a non-honored form is passed, so the flag's purpose (deterministic date-sensitive tests) can't be quietly defeated by a typo or a timezone-aware value.
Proposed behavior
Client-side warning to stderr (non-breaking — still sends) when
--override-timestampis non-empty and carries a confirmed-ignored signal:Z,±HH:MMtimezone offset after the time,T.e.g.
warning: --override-timestamp "...Z" carries a timezone; the server only honors timezone-naive ISO 8601 (e.g. 2030-12-25T09:30:00) and will silently ignore this, falling back to the real clock.Design notes / open questions
YYYY-MM-DDTHH:MM:SSis confirmed honored; whether fractional-seconds or seconds-less forms are honored is unknown, so a positive "warn unless it matches X" risks false positives. Warn only on the confirmed-bad signals above. (Tradeoff: a negative check won't catch pure garbage likenot-a-real-timestamp, which also silently no-ops.)--output json/ scripting: warning goes to stderr so it shouldn't corrupt stdout — confirm that's acceptable.Related