Skip to content

fix(sessions): correct timezone handling for PostgreSQL in DatabaseSessionService#5355

Open
zouyi100 wants to merge 1 commit intogoogle:mainfrom
zouyi100:fix/databasesession-update-wrong-timezone
Open

fix(sessions): correct timezone handling for PostgreSQL in DatabaseSessionService#5355
zouyi100 wants to merge 1 commit intogoogle:mainfrom
zouyi100:fix/databasesession-update-wrong-timezone

Conversation

@zouyi100
Copy link
Copy Markdown

Problem:
create_session already stored UTC naive datetimes for both SQLite and
PostgreSQL, but the corresponding read path (get_update_timestamp) and
write path in append_event only handled SQLite. On non-UTC hosts this
causes session.last_update_time to be off by the local timezone offset
after create_session, and potentially triggers false stale-session errors
after the first append_event call on PostgreSQL.

Three specific inconsistencies:

  1. get_update_timestamp only added UTC tzinfo for SQLite, not PostgreSQL.
  2. append_event wrote local-time naive update_time for PostgreSQL, while
    create_session wrote UTC naive.
  3. get_session / list_sessions did not propagate is_postgresql to
    to_session.

Solution:
Extend the existing SQLite UTC-naive convention to PostgreSQL consistently
across all read and write paths.

Testing Plan

Unit Tests:

  • I have added or updated unit tests for my change.
  • All unit tests pass locally.

pytest tests/unittests/sessions/ --deselect
"tests/unittests/sessions/test_session_service.py::test_get_session_with_config[SessionServiceType.DATABASE]"
169 passed (the deselected test is a pre-existing Windows-only OSError

unrelated to this change)

Manual End-to-End (E2E) Tests:
Tested with SQLite (:memory:) and verified session.last_update_time
returns correct UTC-based POSIX timestamps after create_session and
append_event.

@google-cla
Copy link
Copy Markdown

google-cla bot commented Apr 16, 2026

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

@adk-bot adk-bot added the services [Component] This issue is related to runtime services, e.g. sessions, memory, artifacts, etc label Apr 16, 2026
@adk-bot
Copy link
Copy Markdown
Collaborator

adk-bot commented Apr 16, 2026

Response from ADK Triaging Agent

Hello @zouyi100, thank you for your contribution!

To move forward with this PR, please address the following points from our contribution guidelines:

  • Contributor License Agreement (CLA): It looks like the CLA check has failed. Please sign the Google CLA so we can accept your contribution.
  • Associated Issue: This PR is a bug fix. Could you please create a GitHub issue that describes the problem and link it to this PR?

You can find more details in our contribution workflow guidelines. Thanks!

…ssionService

`create_session` already stored UTC naive datetimes for both SQLite and
PostgreSQL, but the corresponding read path (`get_update_timestamp`) and
write path in `append_event` only handled SQLite, causing incorrect POSIX
timestamps and potential false stale-session errors on non-UTC hosts.

- `get_update_timestamp` / `update_timestamp_tz`: treat PostgreSQL the
  same as SQLite — attach UTC tzinfo before calling `.timestamp()`.
- `to_session`: thread the new `is_postgresql` flag through to
  `get_update_timestamp`.
- `append_event`: use UTC naive datetime for PostgreSQL `update_time`
  (consistent with `create_session`); use UTC-aware datetime for all
  other non-SQLite dialects instead of local-time naive.
- `get_session` / `list_sessions`: propagate `is_postgresql` to
  `to_session`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

services [Component] This issue is related to runtime services, e.g. sessions, memory, artifacts, etc

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants