我们管理后台的历史
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。
多看多学多遇到就不会搞这么萌的笑话……