系统开发过程中常因为时间参数的存储和呈现方式的问题产生争议，再加上考虑不同时区的时间在同一系统存储和展示的情况更为复杂。通常的设计方案是：存储的时候，为了不让数据混乱，统一按照UTC+00:00时区的毫秒级长整型数字时间戳来存储；展示的时候，为了让用户方便，按照用户关注的时区来呈现时间，如：“年-月-日 时:分:秒”。
那么，第一个问题来了。用户关注的时区究竟如何选取呢？难道就一定是用户所在地的时区吗？！
第二个问题，是Java本身的规则一手造成的。比如：1436013000000，这个时间戳是UTC+00:00时区“2015-07-04 12:30:00”对应的毫秒级长整型数字时间戳。在C++当中，无论我们用的计算机配置为何时区，双向转换的结果会是一致的。但如果用Java，转换结果也是关于计算机时区配置的。比如：我们的计算机时区配置为UTC+00:00时区，根据1436013000000这个数字时间戳转换得到的时间就会是“2015-07-04 12:30:00”；如果我们的计算机时区配置为UTC+08:00时区，根据1436013000000这个数字时间戳转换得到的时间就会是“2015-07-04 20:30:00”。Java在这个转换过程中自动为这个参数加上东8区28800000毫秒的时区偏移量。从时间向数字时间戳的转换过程中，Java又会自动为这个参数减掉28800000毫秒。
表面上看起来Java的这个机制很人性化。实则不然，如果运行系统的服务器部署在不同时区的话，麻烦就来了。服务器部署的时区直接影响了时间参数的转换结果。
本文，我就对这两个问题给出一个解决方案。大家可以参考，但是遇到不同情况，建议按照用户的真实需求，具体问题具体分析。
1 理论时区理论时区以被15整除的子午线为中心，向东西两侧延伸7.5度，即每15°划分一个时区，这是理论时区。理论时区的时间采用其中央经线（或标准经线）的地方时。所以每差一个时区，区时相差一个小时，相差多少个时区，就相差多少个小时。东边的时区时间比西边的时区时间来得早。为了避免日期的紊乱，提出国际日期变更线的概念。
夏令时（DaylightSaving Time：DST），又称“日光节约时制”和“夏令时间”，是一种为节约能源而人为规定地方时间的制度，在这一制度实行期间所采用的统一时间称为“夏令时间”。一般在天亮早的夏季人为将时间提前一小时，以充分利用光照资源，从而节约照明用电。各个采纳夏时制的国家具体规定不同。目前全世界有近110个国家每年要实行夏令时。
3 Unix TimeUnix时间戳（英文为Unix epoch， Unix time， POSIX time 或 Unix timestamp）是从1970年1月1日（UTC/GMT的午夜00:00:00）开始所经过的毫秒数，不考虑闰秒。也就是说，1970-1-100:00:00的数字时间戳是0，当前时间的数字时间戳是此时此地的时间相距1970-1-100:00:00的毫秒数。相同的计算规则，但在不同的编程语言中的实现仍有差别，以C++和Java为例。C++认为时间是0时区的，而Java计算是带着系统时区的。
4 时间转换问题解决方案解决第一个问题，方案引入了一个“工程时区”的概念，含义是时间展示的时区标准，也就是说用户查看的时间按照工程时区来展示“年-月-日 时:分:秒”。
解决第二个问题，需要一个转换方法自动屏蔽运行代码的计算机所带时区的影响。无论系统部署在哪里，系统都要能够准确呈现关注对象所在地的时间（不以用户所在地/系统部署地的时区为转移）。因为关注对象的信息才是用户真正关注的。
将关注对象所在地的时间“yyyy-MM-dd HH:mm:ss”转换为UTC+0的毫秒级整型时间戳，关注对象所在地时区最好与工程时区相同，但如果关注对象所在范围跨时区，关注对象所在地时区与工程时区也可以不同，但这样呈现的时间数据会与输入有差别，其含义是与关注对象持续时间同时刻的工程时区的时间。
举例说明，场景：用户在雅典（东2区），预定一张从北京（东8区）飞往夏威夷（西10区）的机票。订票系统部署在纽约（西5区）。系统处理规则：起飞地点是北京，那么系统呈现的起飞时间，当然应该标注清楚北京（东8区）的时间“yyyy-MM-dd HH:mm:ss”；抵达地点是夏威夷，系统呈现的预计到达时间，当然应该标注清楚夏威夷（西10区）的时间“yyyy-MM-dd HH:mm:ss”。系统呈现的时间与用户订票位置——雅典（东2区）的时区、系统部署位置——纽约（西5区）无关。