我们管理后台的历史
18年可以新做的项目,要求我们做管理后台,但是我之前没有前端的任何经验,另外两个小伙伴也没有。只是用 Go 做过简单的页面。只接触过一点点模板的东西,要做一个管理后台,难度可想而知。
但是坚持了下来,19年后台经过两三次的框架重构,算是有模有样了吧。
问题显现
刚开始,我们只有国际版本的后台,使用的是 UTC 时间,管理后台上有很多关于活动时间的设置,之前并没有任何关于时间的标准设计方式。所以后台页面传入到后台的时间格式有两种,一种是时间格式字符串,例如 2020-05-20 20:00,另外一种是以时间戳的方式传递给后端。
时间格式串
问题
- 非 UTC 时区的服务器上,出现了异常【国服和日本服时间异常,因为在解析时,我们使用的是 time.Parse 函数进行的处理,所以在对应的服务上会有异常】。
解决办法
- 在后台使用 time.ParseInLocation 解析成本地服务器的正确时间
时间戳
问题
若服务器与本地时间不一致,则需要传递正确的时间戳到服务器。例如:最开始只有国际版,我们解决这个问题的办法简单又粗暴,直接将时间戳减去了 8 * 3600 秒。因为我们的本地时间是 CST,这样就能传递正确的时间戳到服务器了。但是随着后续新增加的 国服和日本服分别采用了 CST 和 JST,前端就无法正常工作了。加之,服务器端只有两个人了,维护三个版本,许多开发的功能需要同步,所以会异常痛苦。
解决办法
干掉传递时间戳的方式,直接传递时间格式字符串。 这样前台代码就是统一的,对于设置者而言,永远记得我设计的就是服务器的时间,这样再也不用担心合并过程中的“失误”。
前台展示问题
解决了前台往后台传递的问题,但是如何展示呢?
解决方案
- 若不能通过后台直接格式化时间,则显式告诉前台后台使用的时区【因为我们后台,大部分传递到前台的是时间戳,所以我们会将后台所使用的时区传递到前台】。
- 直接由后台根据时间戳转换成时间格式传递出来。【依然有负作用,因为前台可能需要根据时间格式和当前的时间展示一些特殊的状态,这样前台还是需要后台的格式得到时间戳才能进行简单的计算】
总结
- 前台传递给后台使用时间格式字符串,最合理;
- 前台需要知道后台的时区,后台传递时间戳,前台计算会比较简单;
相关操作
修改 Linux 时区
在 CentOS7 和 Ubuntu 18.04 测试过
timedatectl set-timezone UTC # 设置本地时区为 UTC
timedatectl set-timezone Asia/Tokyo # 设置为日本标准时间 即东京
timedatectl set-timezone Asia/Shanghai # 设置为中国标准时间 即上海
查看可用的时区
timedatectl list-timezones
我笑了
看到一个博客说:CST 应该是 “China Shanghai Time”,还好是应该。
其实计算机中应该有好多 ‘ST’,都是标准的意思。例如:stdio.h, unistd.h。
多看多学多遇到就不会搞这么萌的笑话……