feat: show effective AstrBot time in settings

[RC-CHN]

Display AstrBot's effective current time in the WebUI system settings so users can verify the server clock and the timezone currently applied by AstrBot. This helps identify incorrect server time or timezone configuration without treating an unsaved timezone input as the active value.

Modifications / 改动点

• Added the server's current UTC timestamp and effective UTC offset to the system configuration response.

• Added a compact AstrBot current time · UTC+8 2026/08/07 10:31 indicator to the WebUI settings page.

• Based the indicator only on backend-confirmed time data; editing the timezone field does not change it until the configuration is saved successfully.

• Advanced the backend-confirmed time locally with a monotonic clock between synchronizations.

• Matched the existing server-local-timezone fallback when the configured timezone is empty or invalid.

• Added English, Simplified Chinese, and Russian translations for the time indicator.

• Added unit coverage for the server UTC timestamp and configured UTC offset.

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

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

---

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

Show AstrBot�s effective current time and timezone in the settings UI using server-provided UTC timestamp and offset, with a resilient frontend preview and supporting tests and localizations.

New Features:

• Expose server UTC time and effective UTC offset in the system configuration API response.
• Display AstrBot�s current effective time and timezone in the WebUI runtime settings group, based on backend-confirmed data.

Enhancements:

• Advance the displayed AstrBot time locally using a monotonic clock between backend synchronizations while keeping it read-only until configuration save.
• Fallback to the server�s local timezone when the configured timezone is empty or invalid.
• Add localized labels for the time preview indicator in English, Simplified Chinese, and Russian.

Tests:

• Add unit coverage to ensure system config responses include server UTC time and the configured UTC offset.

[sourcery-ai]

Hey - I've found 1 issue

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="dashboard/src/views/Settings.vue" line_range="869-873" />
<code_context>
         }
         systemConfigData.value = res.data.data?.config || {};
         systemConfigMetadata.value = res.data.data?.metadata || {};
+        const parsedServerTime = Date.parse(res.data.data?.server_utc_time || '');
+        const parsedUtcOffset = Number(res.data.data?.server_utc_offset_minutes);
+        serverUtcEpochMs.value = Number.isNaN(parsedServerTime) ? null : parsedServerTime;
+        serverUtcOffsetMinutes.value = Number.isFinite(parsedUtcOffset) ? parsedUtcOffset : null;
+        serverClockAnchorMs.value = serverUtcEpochMs.value === null ? null : performance.now();
+        serverClockTickMs.value = serverClockAnchorMs.value;
         systemConfigLastSavedSnapshot.value = JSON.stringify(systemConfigData.value || {});
</code_context>
<issue_to_address>
**suggestion:** The server time parsing / state wiring is duplicated and could be centralized.

The parsing and initialization of `serverUtcEpochMs`, `serverUtcOffsetMinutes`, and `serverClockAnchorMs` from `server_utc_time` / `server_utc_offset_minutes` is repeated in both `loadSystemConfig` and `saveSystemConfig` (after `systemConfigApi.get`). Please extract this into a shared helper (e.g. `applyServerTimePayload(data)`) to keep the two paths consistent and simplify future changes to the time preview behavior.

Suggested implementation:

```
const systemConfigGroups = computed(() => {
    const systemSection = systemConfigMetadata.value?.system_group?.metadata?.system || {};
    const systemItems = systemSection.items || {};
});

/**
 * Apply server time fields from an API payload to the reactive clock state.
 * Keeps parsing / initialization logic centralized for load/save flows.
 */
const applyServerTimePayload = (payload: {
    server_utc_time?: string | null;
    server_utc_offset_minutes?: number | string | null;
} | null | undefined) => {
    const parsedServerTime = Date.parse(payload?.server_utc_time || '');
    const parsedUtcOffset = Number(payload?.server_utc_offset_minutes);

    serverUtcEpochMs.value = Number.isNaN(parsedServerTime) ? null : parsedServerTime;
    serverUtcOffsetMinutes.value = Number.isFinite(parsedUtcOffset) ? parsedUtcOffset : null;
    serverClockAnchorMs.value = serverUtcEpochMs.value === null ? null : performance.now();
    serverClockTickMs.value = serverClockAnchorMs.value;
};

```

```
        }
        systemConfigData.value = res.data.data?.config || {};
        systemConfigMetadata.value = res.data.data?.metadata || {};
        applyServerTimePayload(res.data.data);
        systemConfigLastSavedSnapshot.value = JSON.stringify(systemConfigData.value || {});

```

The same parsing / initialization logic appears in the `saveSystemConfig` flow after `systemConfigApi.get` (and any other call sites that update `serverUtcEpochMs`, `serverUtcOffsetMinutes`, `serverClockAnchorMs`, and `serverClockTickMs` from `server_utc_time` / `server_utc_offset_minutes`). Those code paths should be updated to call `applyServerTimePayload(...)` instead of duplicating the parsing logic, using the same payload shape (`res.data.data` or equivalent). The existing error-case reset block (which sets all server clock fields to `null`) can remain as-is, since it represents a distinct behavior rather than payload parsing.
</issue_to_address>

---

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.}

[sourcery-ai]

suggestion: The server time parsing / state wiring is duplicated and could be centralized.

The parsing and initialization of serverUtcEpochMs, serverUtcOffsetMinutes, and serverClockAnchorMs from server_utc_time / server_utc_offset_minutes is repeated in both loadSystemConfig and saveSystemConfig (after systemConfigApi.get). Please extract this into a shared helper (e.g. applyServerTimePayload(data)) to keep the two paths consistent and simplify future changes to the time preview behavior.

Suggested implementation:

const systemConfigGroups = computed(() => {
    const systemSection = systemConfigMetadata.value?.system_group?.metadata?.system || {};
    const systemItems = systemSection.items || {};
});

/**
 * Apply server time fields from an API payload to the reactive clock state.
 * Keeps parsing / initialization logic centralized for load/save flows.
 */
const applyServerTimePayload = (payload: {
    server_utc_time?: string | null;
    server_utc_offset_minutes?: number | string | null;
} | null | undefined) => {
    const parsedServerTime = Date.parse(payload?.server_utc_time || '');
    const parsedUtcOffset = Number(payload?.server_utc_offset_minutes);

    serverUtcEpochMs.value = Number.isNaN(parsedServerTime) ? null : parsedServerTime;
    serverUtcOffsetMinutes.value = Number.isFinite(parsedUtcOffset) ? parsedUtcOffset : null;
    serverClockAnchorMs.value = serverUtcEpochMs.value === null ? null : performance.now();
    serverClockTickMs.value = serverClockAnchorMs.value;
};

        }
        systemConfigData.value = res.data.data?.config || {};
        systemConfigMetadata.value = res.data.data?.metadata || {};
        applyServerTimePayload(res.data.data);
        systemConfigLastSavedSnapshot.value = JSON.stringify(systemConfigData.value || {});

The same parsing / initialization logic appears in the saveSystemConfig flow after systemConfigApi.get (and any other call sites that update serverUtcEpochMs, serverUtcOffsetMinutes, serverClockAnchorMs, and serverClockTickMs from server_utc_time / server_utc_offset_minutes). Those code paths should be updated to call applyServerTimePayload(...) instead of duplicating the parsing logic, using the same payload shape (res.data.data or equivalent). The existing error-case reset block (which sets all server clock fields to null) can remain as-is, since it represents a distinct behavior rather than payload parsing.