update docs

Author: wu-clan

docs/.vuepress/navbar.ts

@@ -125,6 +125,7 @@ export const myNavbar: ThemeNavItem[] = defineNavbarConfig([
                 items: [
                     {
                         text: '知识星球',
+                        badge: { text: '重制中', type: 'warning' },
                         icon: 'ph:planet-fill',
                         link: '/planet'
                     },

docs/.vuepress/sidebar.ts

@@ -36,16 +36,16 @@ export const mySidebar: ThemeSidebarMulti = {
                 { text: 'CRUD', link: 'CRUD' },
                 { text: '分页', link: 'pagination' },
                 { text: '接口响应', link: 'response' },
-                { text: '国际化', link: 'i18n', badge: 'NEW' },
+                { text: '国际化', link: 'i18n' },
                 { text: 'JWT', link: 'jwt' },
                 { text: 'RBAC', link: 'RBAC' },
-                { text: 'OAuth 2.0', link: 'oauth2' },
-                { text: '自定义异常', link: '/planet', badge: { text: '专业版', type: 'warning' } },
-                { text: '节流', link: 'limit' },
                 { text: '跨域', link: 'CORS' },
-                { text: 'SQLA 事务', link: 'transaction' },
+                { text: '时区', link: 'timezone' },
+                { text: '节流', link: 'limit' },
                 { text: '切换主键', link: 'pk' },
                 { text: '切换数据库', link: 'db' },
+                { text: '事务', link: 'transaction' },
+                { text: 'OAuth 2.0', link: 'oauth2' },
                 { text: '数据权限', link: '/planet', badge: { text: '专业版', type: 'warning' } },
                 { text: '代码生成', link: 'code-generation' },
                 { text: 'SocketIo', link: '/planet', badge: { text: '专业版', type: 'warning' } },

docs/backend/reference/timezone.md

@@ -0,0 +1,52 @@
+---
+title: 时区
+---
+
+我们为全局精心设计了统一时区，现在，这是一件非常轻松的工作，只需修改 `backend/core/conf.py` 中的时区配置即可改变全局时区
+
+::: caution
+时区一旦确定，强烈建议不要后期修改，否则可能造成持久化数据时间信息紊乱！
+:::
+
+## 架构应用
+
+无论在架构何处调用时间模块，我们都应使用 `backend/utils/timezone.py` 中提供的现有方法，而不是直接调用 datetime 相关模块
+
+## 数据库
+
+在数据库中处理时区是一件令人头疼的事，常见的方式有以下 3 种：
+
+- 全部存读为 UTC，前端转化（利于国际化管理）
+- 全部存读当前时区时间，根据前端传入的时区进行转换（利于本地化管理）
+- 全部存储为数值时间戳，前端转化（极其不易管理，但易操作）
+
+让我们来看一个经典案例：
+
+::: chat title="群聊"
+{:2025-08-26 12:44:00}
+
+{王}
+请教大佬，为啥我查询的时间用的不同的时区和时间戳，返回的数据却是一样的？
+
+![question_db_timezone](/images/question_db_timezone.png)
+
+数据库用的是 mysql，原则上这两个 datetime 的时间戳是不一样的，但是查出来的数据是一样的结果；
+
+{王}
+我直接写 sql 查询，这个两个是符合预期结果的，第一个有数据，第二个查不到；
+
+![question_sql_timezone](/images/question_sql_timezone.png)
+
+这个切换到pg数据库后查询符合预期结果的；
+
+{.}
+**timezone**: not used by the MySQL dialect.
+
+sqlalchemy 和所有 python mysql 驱动默认都不处理 mysql 时区信息，通常是直接丢弃，即便使用 TIMESTAMP 类型
+
+{.}
+更具体的：[sqlalchemy/1985](https://github.com/sqlalchemy/sqlalchemy/issues/1985)
+:::
+
+为此，我们使用了第 2 种解决方案，并创建了自定义 TimeZone 类型，位于 `backend/common/model.py` 文件中，我们可以通过 IDE
+点击类名快捷查看使用方式

docs/questions.md

@@ -63,30 +63,5 @@ return await self.select_order(  # [!code word:noload]
 
 ## 数据库时区陷阱
 
-MySQL 不支持时区类型（数据库驱动设计便是如此），而 PostgreSQL 拥有完美的时区类型，以下是一个时区相关的经典案例
-
-::: chat title="群聊"
-{:2025-08-26 12:44:00}
-
-{王}
-请教大佬，为啥我查询的时间用的不同的时区和时间戳，返回的数据却是一样的？
-
-![question_db_timezone](/images/question_db_timezone.png)
-
-数据库用的是 mysql，原则上这两个 datetime 的时间戳是不一样的，但是查出来的数据是一样的结果；
-
-{王}
-我直接写sql查询，这个两个是符合预期结果的，第一个有数据，第二个查不到；
-
-![question_sql_timezone](/images/question_sql_timezone.png)
-
-这个切换到pg数据库后查询符合预期结果的；
-
-{.}
-**timezone**: not used by the MySQL dialect.
-
-sqla 不处理 mysql 时区，即便换成 TIMESTAMP
-
-{.}
-更具体的：[sqlalchemy/1985](https://github.com/sqlalchemy/sqlalchemy/issues/1985)
-:::
+MySQL 不支持时区存储类型，而 PostgreSQL 拥有完美的时区类型，所以在数据库中存储时间列确实是一件令人头疼的事情，不过我们已经实现完美方案，兼容
+pgsql 和 mysql，[查看详情](./backend/reference/timezone.md)