Inconsistent timezone handling for PostgreSQL between create_session and append_event in DatabaseSessionService

[zouyi100]

🔴 Required Information

Describe the Bug:
Inconsistent timezone handling for PostgreSQL between create_session and append_event methods in DatabaseSessionService. The create_session method stores UTC time with timezone removed for PostgreSQL, while append_event method stores local time (no timezone parameter) for PostgreSQL. This inconsistency may cause StorageSession.update_time to have different time baselines depending on which method was called.

Steps to Reproduce:

1. Set up ADK with PostgreSQL as the database backend
2. Create a session using DatabaseSessionService.create_session()
3. Append an event using DatabaseSessionService.append_event()
4. Compare the create_time/update_time values in StorageSession table
5. Observe that timestamps may have different time baselines (UTC vs local time)

Expected Behavior:

• Both create_session and append_event should handle PostgreSQL timestamps consistently, storing UTC time with timezone information removed for both methods.

Observed Behavior:

• create_session (L461-L465): PostgreSQL uses UTC time with tzinfo=None

• append_event (L731-L737): PostgreSQL uses local time (no timezone parameter passed to datetime.fromtimestamp())

This can cause timestamps to be inconsistent when the server timezone differs from UTC.

Environment Details:

• ADK Library Version (pip show google-adk): 1.29.0
• Desktop OS:** Windows
• Python Version (python -V): 3.13

Model Information:

• Are you using LiteLLM: N/A
• Which model is being used: N/A

---

[surajksharma07]

@zouyi100 append_event hits the else branch for PostgreSQL (L735–736 in database_session_service.py) and calls datetime.fromtimestamp(event.timestamp) without a tz argument, so it stores local time instead of UTC.

Meanwhile create_session correctly converts to UTC first, which is where the drift comes from.

As a workaround worth trying: add is_postgresql = self.db_engine.dialect.name == _POSTGRESQL_DIALECT near the existing is_sqlite check and update the condition to if is_sqlite or is_postgresql: — that's exactly the same pattern create_session already uses, so it should slot in cleanly.

Could you verify if that resolves the timestamp drift on your setup?

[zouyi100]

Hi @surajksharma07
Could you please check this PR #5355
This fixed my issue on PostgreSQL but have not test on SQLite and MySQL.
If need i can try tomorrow.

[surajksharma07]

Thanks for the quick PR @zouyi100

SQLite should be fine — it has its own separate if is_sqlite: path that was already correct and your change doesn't touch it.

For MySQL, the else branch now calls datetime.fromtimestamp(event.timestamp, timezone.utc) which stores UTC with timezone info — MySQL handles that correctly, so it should be safe, but if you have a few minutes it'd be good to confirm just to be sure.

Team is looking more into it.