diff --git a/site/blog/posts/ssr-timezone.md b/site/blog/posts/ssr-timezone.md
index 75ee793..fed4114 100644
--- a/site/blog/posts/ssr-timezone.md
+++ b/site/blog/posts/ssr-timezone.md
@@ -1,21 +1,27 @@
 ---
-title: 解决服务端渲染因时区问题导致客户端结果不匹配
+title: 时间格式化在SSR下的偏差
 date: 2023-10-05T22:35:35+08:00
 category: next
 tags: [next, js, ssr]
-description: 服务端渲染时，因服务器与客户端所在地时区的不同，造成应用在服务器端渲染时，格式化的时间不满足客户端需求的解决方案。
+description: 在进行SSR服务端渲染时，因服务器与客户端所在地时区的不同，造成应用在服务器端渲染时，格式化后的时间结果与实际结果出现偏差。偏差大小取决于服务器时区与客户端时区差值。
 ---
 
-在习惯了`csr`渲染的今天，我们在处理时间时通常采用时间格式化插件如：`dayjs`、`moment`(已停止维护)、`date-fns`等时间库来解决，由于是在客户端，因此很少出现时间不正确的问题，因为这些时间插件已经在基于客户端时区环境帮我们处理好了。但在服务端渲染时，由于服务器一般会统一个时区标准，通常为零时区（也称中时区），以此为标准存储、处理时间，因此在服服器渲染时间数据后，呈现给用户的都是以服务器时区为标准的时间。由于不同用户访问所在时区不同，但时间返回又是服务器时间，不符合生活上直观的时间，因此我们该如何解决这类问题呢？
-
-直接查看：[解决方案](#解决方案)
-
 ### TOC
 
 ### 背景
 
-最近在处理`nextjs`服务端渲染时，遇到时间格式化后在，客户端展示晚上8小时的问题，刚开始想着是如何处理服务器时区问题，因此查找了很多关于修服务器配置，以及更改`nodejs`环境配置的资料，但收效甚微。后来在与做后端的朋友聊及此问题时，发现从一开始我的方向都错了。因此在这里总结一下，以供需要的同学处理类似问题。
+最近在处理`nextjs`服务端渲染时，遇到时间格式化后在，客户端展示晚了8小时的问题，刚开始想着是如何处理服务器时区问题，因此查找了很多关于修服务器配置，以及更改`nodejs`环境配置的资料，但收效甚微。后来在与做后端的朋友聊及此问题时，发现从一开始我的方向都错了。因此在这里总结一下，以供需要的同学处理类似问题。
+
+#### 为什么是晚了8小时？
+在计算机中时间的生成都是一个唯一值，用UNIX表示则为一个毫秒级整数，我们平常所看见的是格式化后的时间字符串，例如：`2022-22-22 22:22:22`。这个字符会因为我们本地计算机配置的时区不同，而格式化后有所差异，例如，在国内个人计机上时间为: `2022-22-22 22:22:22`，在英国个人计算机上则为: `2022-22-22 14:22:22`，这是因为国内使用的是`东8区`时区时间，英国为`0时区`时间，所以时间上相应偏差8时间。
 
+那么由于，我们程序在服务器上的时间配置为`0时区`，所以在服务器端格式化时间时以`0时区`为基准，而我们在本地计算机访问时，本地计算机时区为`东8区`，所以就出现了格式化后的时间字符串晚8小时的情况。
+
+> 全球共分24个时区，以0时区为基准，向东增加，向西减少，增减为地区对应时区。
+
+**注意：时间是唯一的，本地时间（格式化后时间）是相对的（需要加上时区）**
+
+直接查看：[解决方案](#解决方案)
 
 ### 时间相关概念