fix: display cron last_run_at in local timezone

[KBVsent]

On the scheduled tasks page of the WebUI, last_run_at was displayed in UTC while next_run_time was correctly displayed in the browser's local timezone. The root cause is inconsistent datetime semantics crossing the SQLite boundary: last_run_at was written via datetime.now(timezone.utc) (UTC-aware), while next_run_time came from APScheduler as an aware datetime in the job's configured timezone. SQLite strips tzinfo on round-trip, so the serializer emitted naive ISO strings without offsets. The frontend's new Date(iso).toLocaleString() then interpreted both as local time — correct by coincidence for next_run_time, but shifted for last_run_at.

Modifications / 改动点

• astrbot/core/cron/manager.py: _get_next_run_time now normalizes APScheduler's aware datetime to UTC before persisting, so all cron datetime columns share the convention "stored as UTC".
• astrbot/dashboard/routes/cron.py: the route serializer attaches tzinfo=UTC to any naive datetime before isoformat(), so the API emits ISO strings with an explicit +00:00 offset that the frontend converts to the user's local timezone.

• This is NOT a breaking change. / 这不是一个破坏性变更。

Screenshots or Test Results / 运行截图或测试结果

Before:

After:

---

Checklist / 检查清单

• 😊 If there are new features added in the PR, I have discussed it with the authors through issues/emails, etc.
  / 如果 PR 中有新加入的功能，已经通过 Issue / 邮件等方式和作者讨论过。

• 👀 My changes have been well-tested, and "Verification Steps" and "Screenshots" have been provided above.
  / 我的更改经过了良好的测试，并已在上方提供了“验证步骤”和“运行截图”。

• 🤓 I have ensured that no new dependencies are introduced, OR if new dependencies are introduced, they have been added to the appropriate locations in requirements.txt and pyproject.toml.
  / 我确保没有引入新依赖库，或者引入了新依赖库的同时将其添加到 requirements.txt 和 pyproject.toml 文件相应位置。

• 😮 My changes do not introduce malicious code.
  / 我的更改没有引入恶意代码。

Summary by Sourcery

Ensure cron job timestamps are stored and serialized with consistent UTC timezone information so the WebUI can display them correctly in the user’s local time.

Bug Fixes:

• Fix inconsistent timezone handling causing cron job last_run_at to display in the wrong timezone in the WebUI.

Enhancements:

• Normalize APScheduler next_run_time values to UTC before persistence so all cron timestamps follow a unified storage convention.
• Ensure API serialization of cron timestamps attaches UTC to naive datetimes before emitting ISO strings for the dashboard.

[sourcery-ai]

Hey - I've left some high level feedback:

• Consider extracting the "naive == UTC" normalization into a shared helper (e.g., ensure_utc(dt) in a datetime utils module) so the manager and route layers don’t each reimplement the same assumption separately.
• Since the serializer now implicitly treats all naive datetimes as UTC, it might be safer to enforce this at the data model/DB boundary (e.g., normalizing to UTC before persistence) so that future code paths can’t accidentally write local-time naive values that will later be misinterpreted.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Consider extracting the "naive == UTC" normalization into a shared helper (e.g., `ensure_utc(dt)` in a datetime utils module) so the manager and route layers don’t each reimplement the same assumption separately.
- Since the serializer now implicitly treats all naive datetimes as UTC, it might be safer to enforce this at the data model/DB boundary (e.g., normalizing to UTC before persistence) so that future code paths can’t accidentally write local-time naive values that will later be misinterpreted.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[gemini-code-assist]

Code Review

This pull request standardizes timezone handling for cron job timing. Specifically, it updates the cron manager to return UTC-aware datetimes for the next run time and modifies the job serialization logic to ensure datetime fields are explicitly marked as UTC before being converted to ISO format. I have no feedback to provide.