Skip to content

FIX: return aware UTC created_at from conversation stats - #3661

Open
Manohar Paturi (ManoharPaturi) wants to merge 1 commit into
microsoft:mainfrom
ManoharPaturi:fix/conversation-stats-created-at-utc
Open

Manohar Paturi (ManoharPaturi) wants to merge 1 commit into
microsoft:mainfrom
ManoharPaturi:fix/conversation-stats-created-at-utc

Conversation

@ManoharPaturi

Copy link
Copy Markdown
Contributor

Description

Fixes #3660

get_conversation_stats_async builds created_at from a raw MIN(timestamp) aggregate that bypasses the UTCDateTime result processor, so the value came back timezone-naive on both SQLite and Azure SQL and serialized without an offset. Clients then rendered conversation creation times shifted by the viewer's local UTC offset, while the attack created_at next to it in the same UI stayed aware.

Both backends now reattach UTC when the aggregate comes back naive, so every timestamp PyRIT returns carries the same aware UTC form.

Tests and Documentation

Added a regression that inserts one message through the real store and asserts created_at carries a UTC offset. It fails on main and passes with the change. The full sqlite and azure memory suites pass (189 tests) and ruff is clean.

No documentation change needed, so I did not run JupyText.

The raw MIN(timestamp) aggregate bypasses the UTCDateTime result processor on both backends, so the parsed value carried no offset and clients rendered conversation creation times shifted by their local UTC offset. Reattach UTC when the aggregate comes back naive.

Signed-off-by: Manohar Paturi <186662190+ManoharPaturi@users.noreply.github.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Conversation stats return a timezone-naive created_at while the rest of the API returns aware UTC

1 participant