Skip to content

fix(models): use consistent naive_utc_now for created_at/updated_at, not DB server time#38787

Open
iruzen-dono wants to merge 1 commit into
langgenius:mainfrom
iruzen-dono:fix/consistent-timestamps-mysql-utc
Open

fix(models): use consistent naive_utc_now for created_at/updated_at, not DB server time#38787
iruzen-dono wants to merge 1 commit into
langgenius:mainfrom
iruzen-dono:fix/consistent-timestamps-mysql-utc

Conversation

@iruzen-dono

Copy link
Copy Markdown

The Bug

On MySQL, func.current_timestamp() returns the database server's local time (e.g., CST = UTC+8), while the service code updates updated_at with naive_utc_now() (Python UTC). Since MySQL's DATETIME type does not store timezone info, created_at and updated_at end up with different timezone offsets — typically an 8-hour discrepancy for users in CST.

The Fix

Switch Conversation and Message models from DB-side server_default=func.current_timestamp() / onupdate=func.current_timestamp() to Python-side default=naive_utc_now / onupdate=naive_utc_now.

This ensures both created_at and updated_at always get UTC values, regardless of the database server's timezone.

Changes

  • api/models/model.py: import naive_utc_now from libs.datetime_utils and replace func.current_timestamp() references with naive_utc_now

Affected columns

Model Column Before After
Conversation created_at server_default=func.current_timestamp() default=naive_utc_now
Conversation updated_at server_default=func.current_timestamp(), onupdate=func.current_timestamp() default=naive_utc_now, onupdate=naive_utc_now
Message created_at server_default=func.current_timestamp() default=naive_utc_now
Message updated_at server_default=func.current_timestamp(), onupdate=func.current_timestamp() default=naive_utc_now, onupdate=naive_utc_now

References

Closes #38553

…not DB server time

On MySQL, `func.current_timestamp()` returns the database server's
local time (e.g., CST/UTC+8), while the service code updates
`updated_at` with `naive_utc_now()` (Python UTC). Since MySQL's
DATETIME type does not store timezone, this creates an 8-hour
discrepancy between created_at and updated_at.

Fix by switching Conversation and Message from DB-side
`server_default=func.current_timestamp()` / `onupdate=func.current_timestamp()`
to Python-side `default=naive_utc_now` / `onupdate=naive_utc_now`.
This ensures both fields always get UTC values regardless of the
database server timezone.

Fixes langgenius#38553
Copilot AI review requested due to automatic review settings July 11, 2026 01:44
@dosubot dosubot Bot added the size:S This PR changes 10-29 lines, ignoring generated files. label Jul 11, 2026

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

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

Labels

size:S This PR changes 10-29 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Timezone inconsistency in message/conversation timestamps leads to 8-hour discrepancy on MySQL

2 participants