部分时间概念

UTC时间Coordinated Universal Time (UTC) is the basis for civil time today. This 24-hour time standard is kept using highly precise atomic clocks combined with the Earth's rotation.UTC时间是一个标准时间，其实就是一个参考系，粗略的理解就是刻度线上的零，坐标系上的原点，所有其他时间都是以与UTC为参考换算出来的。这个时间是以1970年01月01日00时00分00秒开始算起的，不属于任何一个时区。Unix时间戳Unix时间戳其实就是UTC时间相对于1970年01月01日00时00分00秒流逝的秒数，这是一个标量 。逻辑上的时间判断 ，大多可以直接用这个来比较，比如是否到时间开启了，是否到时间结束了，直接用这个数值，可以减少时区给思维带来的干扰，特别是避免了使用不同时区来进行比较的错误。GMT注意GMT和UTC是有区别的，虽然他们实际是同样的时间值，但是UTC是一个标准的参考时间，并不带时区信息，GMT是一个时区时间，他们的关系大概就是GMT = UTC + 0时区秒数。本地时间相对于UTC，算上时区差的时间，本地时间 = UTC + 时区差。所以北京的本地时间 = UTC + 东八时区差。总结以前没做过海外项目，第一次接触这几个概念的时候，还真给搞懞了，后来接了个时区改造的需求，查了一下资料，踩了一些坑，算是有点了解了。写个笔记，不保证完全正确，只是给自己梳理一下。目前项目组的做法是：登录的时候，服务器给客户端下发Unix时间戳、服务器所在的时区。除此之外客户端设备还可以获取自己所在的时区。那么根据Unix时间戳，SrvTimeZone，CliTimeZone这三个数据，基本可以满足所有的时间显示需求。

比如有些地区的需求，需要显示的是服务器的时间，那用UTC + SvrTimeZone就可以满足，相反如果需要显示客户端当地的时间，用UTC + CliTimeZone。

比如知道某个活动的开启的服务器时间，需要显示对应的客户端时间，那么根据服务器开启的时间，还有服务器与客户端的时区差，就可以算出相对时间。 CliShowTime = ( CliTimeZone - SvrTimeZone ) + SvrTime

还有些比较坑的地方，就是很多配置一般会配个开始时间和结束时间，都需要改成配置开始时间+持续时间方式，这样的话判断逻辑好写一些，特别当天多个时段开启的活动，这种配置方式可以避免跨天时间判断逻辑错误的问题。另外对于一些配置为星期几的时间，可能就更加行不通了，因为不同时区的地方，可能会有出现跨天的情况，你不能说配了个周三开启这样 ，因为有可能跨天到周四。

另外就是配置里填的时间，对于运营人员来说，应该是运营人员当地的时间或者说是服务器当地的时间，这样可以降低运营人员配置出错概率。但是客户端读取这些配置的时候，可能就需要进行一定的转换了，比如服务器是0时区，客户端却在东8区，那么客户端显示这些配置的时间，需要加上8个时区的偏移。对于服务器下发的配置，一般都是由服务器转换成UTC时间下发。

另外就是客户端显示的问题了。对于不同的地区，显示的时间格式可能有各种各样。比如有些地区希望年月日时分秒全显示，而有些却又只希望显示年月日，但是翻译格式是已经固定下来的。这个问题比较单复数问题还要恶心。那么要怎么解决呢？写一个翻译格式规则来判断应该怎么显示吗？ 这个成本有点大，翻译人员配起来也蛋痛，需要编写类似于正则表达式的东西。同事利用C#的一个trick，提出了一个解决办法。就是客户端这边，统一按顺序将年月日时分秒的参数都传给翻译接口，然后通过翻译格式来控制显示。简单来说就是控制String.Format的参数。比如如果要显示年月日，翻译那边只填，这样多出来的参数，C#会自动忽略掉。比如如果需要月日年这样显示 ，那么翻译那边只需要凋乱一下顺序这样就好了。

待续

参考资料：timeanddata.com