Skip to content

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

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

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.

@iruzen-dono

Copy link
Copy Markdown
Author

Hi maintainers 👋 this PR fixes a consistency issue where model created_at/updated_at used DB server time instead of naive_utc_now, which causes timestamp drift when the DB runs in a different timezone. The fix is minimal (+7/-6). Would appreciate a review when possible.

@crazywoola

Copy link
Copy Markdown
Member

Hi @iruzen-dono, thanks for opening this pull request.

Why this is being closed

Issue #38553 has multiple open pull requests. Under the duplicate-PR rule, pull requests from the issue author are ranked first, then creation time is used as the FIFO tie-breaker. PR #38554 is the retained pull request, so this one is being closed.

Next steps

Please coordinate on PR #38554 if you would like to contribute further. Thank you for understanding.

@crazywoola crazywoola closed this Jul 23, 2026
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

3 participants