Java服务端时区的几点思考

最近半年来开发的几个模块，涉及到了预定，检查，和查询。每个模块相同的都遇到了时间的处理，每次遇到的问题都不太一样。总结一下，避免以后走弯路。

1. 时区概念

   时区（Time Zone)是地球上的区域使用同一个时间定义。1884年在华盛顿召开国际经度会议时，为了克服时间上的混乱，规定将全球划分为24个时区。
   

2. GMT，UTC，UNIX时间戳

   GMT，格林尼治时间。理论上来说，格林尼治标准时间的正午是指当太阳横穿格林尼治子午线时（也就是在格林尼治上空最高点时）的时间。但由于地球在它的椭圆轨道里的运动速度不均匀，这个时刻可能与实际的太阳时有误差，最大误差达16分钟。原因在于地球每天的自转是有些不规则的，而且正在缓慢减速，因此格林尼治时间基于天文观测本身的缺陷，已经不再被作为标准时间使用。

   UTC，协调世界时（英：Coordinated Universal Time ，法：Temps Universel Coordonné），又称世界统一时间，世界标准时间，国际协调时间。作为调整，引入了闰秒机制。英文（CUT）和法文（TUC）的缩写不同，作为妥协，简称UTC。UTC与GMT的时间差距不大，但是因为GMT的缺陷，UTC已被作为世界统一的时间标准。

   UNIX时间戳，从协调世界时1970年1月1日0时0分0秒起至现在的总秒数，不考虑闰秒 这么做应该是为了简化逻辑。

任何一个绝对的时间点，绝对的时间是一致的，只不过人为地划分了时区以后，我们以一个标准去工作学习，休息。在格林尼治的哥们吃着炸鱼薯条作为午饭抱怨腐国伙食差的时候，身在北京的我们已经看完了新闻联播，而此时的在洛杉矶的老美可能刚刚进入梦乡。

Java内部的时间计算我的理解是在值的计算都以Long型的Unix时间戳计算，但是在转成Date，或者使用DateFormat进行格式化输出为方便人类识别的时候，会结合时区进行转化。

在日常的和日期相关的计算中，常见有将Date转换为固定格式的字符串，或者将一定格式的字符串转换为日期。在这两个过程中，有时会难以思考其中的过程。

其实形如”2017-05-31 22:09:00”这样的字符串时间并没有时区的概念，而Unix时间戳则是某个时刻的绝对时间，也就是某个时刻零时区的绝地时间。

SimpleDateFormat在实例化的时候，会查看是否手动制定了时区，如果有的话使用指定的时区，否则使用系统默认的时区；SimpleDateFormat进行字符串解析的时候，会认为这个时间是内部持有那个时区的时间，然后将这个时区转换为同一时刻的零时区Unix时间戳。

在使用SimpleDateFormat将一个Date时间转为为固定格式的时间时候，实际就是对字符串解析过程的逆过程。

另外在使用Date date = new Date(Long timeStamp)的时候，Date内部也持有了一个TimeZone对象，在使用System.out.println(date)的时候会自动使用内部的时区对象进行字符串的转化。

其实无论怎样转化，只要服务端使用统一的标准，可以减少不同时区之间的转换和思考过程，更不易产生错误。

客户端的时间是不可信的，一定要使用服务端时间。
服务端的时间在进行国际化的时候，需要考虑时区对业务的影响。
时区除了影响时间值的计算外，对某些字符串信息的格式化也有重要影响。