在国际化运用中，对日期/時间的处置远比你预料中的更难，尤其是当涉及到时区时间的情况下。怎么会那么难?大家该如何解决它?请听我为你一一分析。
几乎任何的体系都离不开“時间”的定义，以致于大部分语言表达(以及默认设置库)都界定了日期/時间等种类。
可是，大家日常常说的“時间”这个词事实上包括了好几个类似却有细微差别的定义。假如不可以分辨他们，会让你的开发设计工作中提供许多苦恼。
一、基本要素
1. 时区时间(Timezone)
在信息化系统中，时间观念的搞混通常和时区时间相关。这也是许多系统软件从本地化翻译运用发展趋势成经济全球化运用时的一大阻碍。
因为全国各地日出日落的时时刻刻不一样，因此全世界一共分成 24 个时区时间，每一个时区时间跨过 360/24=15 个经纬度。例如英国伦敦坐落于北京市的西边，那麼当北京市的阳光早已冉冉升起的情况下，英国伦敦还需要再过 8 钟头才可以迈入拂晓。换句话说，英国伦敦比北京市晚 8 钟头。而日本东京坐落于北京市的东边，因此日本东京的日出比北京市早 1 钟头。
如果我们想要知道当北京是下午 12:00 的情况下，日本东京是啥時间，可以先用 12:00 减掉现阶段时区时间 08:00，转换成伦敦时间 04:00，再再加上总体目标时区时间 09:00，就取得了东京时间 13:00。
2. 零时区
地球是圆的，北京市比英国伦敦早8钟头我觉得就相当于比英国伦敦晚16钟头，究竟谁比谁早呢?大家既可以把这个时间差表明为 8，还可以表述为-16，究竟怎么写呢?我们要先明确一个规范。
最先，要明确一个零时区。
尽管一切一个位置都能够做为零时区，但有着全世界第一座航海钟的法国格林威治天文斩获了此项荣誉，而通过那边的子午线(经线)，被称作本初子午线。它上下各7.5度的范畴称为零时区，再往西一个时区时间就称为西一区。
在我们自东往西旅游的情况下，是在追着阳光走，因而每过一个时区时间，就需要把表拨慢一个小时才可以跟当地时间保持一致，大家把这个“拨慢”的姿势，记作 -01:00，相反则是 01:00。假如从英国伦敦往北京市走，必须从西往东走八个时区时间，因而北京市的时区时间就记作 08:00。
3. 日界限(国际性日期变动线)
在曲面上，与它相对性的那一条子午线，恰好是 12:00 区和 -12:00 区的交界线。这根线很独特，由于如果你自西向东翻过它的情况下，即是比英国伦敦早了13钟头，从另一个方位看来，也是比英国伦敦晚了11钟头。如同数学的进位一样，他们的日期应该是不一样的。当自西向东翻过日界限的情况下(迎着朝阳区)，日期应当减一，相反(追逐落日)，则应当加一。
假定有一个人于下午 12:00 乘飞机从英国伦敦考虑，自西向东(追着阳光)做环游世界。以这架飞机的速度，正好每钟头掠过一个时区时间，因此，每过一个小时，他都需要把表拨慢一个小时(-01:00)。也就是说，大家的主角一直日常生活在中午 12:00，而阳光也的确一直在他的头上，他的认知時间和表里的时间是一致的，那样就规避了他顶着太阳说“现在是深夜”的荒诞感。可是，当他抵达日界限的情况下，还需要做另一件事。因为他是在自西向东穿越重生日界限，因此他还需要把日期加一。他一直往前，等返回英国伦敦走下飞机的情况下，他表里的时间是第二天下午 12:00，而当地时间也正好是第二天的 12:00，他自己恰好在飞上天了一整天。那样，全部的时间段就都对上。
可是如果我们细心看时区表，便会发觉有一些时区时间被标识为 13:00、 14:00，这是怎么一回事呢?或是由于日界限。由于尽管日界限绝大多数坐落于水上，但依然会越过有些人日常生活的陆上。假如把同一个地区的人区划到不一样的日期，会产生许多不方便，因此日界限在中间拐了好多个弯，而这种转弯的地区，当然就发生了像 13:00、 14:00 那样的古怪时区时间。
4. 夏时制
一到夏季，大白天就越来越较长，尤其是高纬度地区会更显著，到了北极圈或南极洲，阳光一天到晚都不容易落下，这就是极夜。
为了更好地灵活运用自然界的赠予，有一些地区会推行夏时制，换句话说到了夏季，就人为因素把表拨快一个小时，让大家尽早醒来、早点睡觉，那样可以减少一些照明灯具的水电费。我国以前短暂性推行过两年夏时制，但是之后觉得它产生的不良影响超出盈利，就取消了。可是全世界依然有很多地区执行夏时制，当设计方案经济全球化运用的情况下，务必得考量它。
5. 时时刻刻(Instant)
或许你认识到了，当英国伦敦是下午十二点时(阳光就在空)，坐落于英国伦敦西边的法国巴黎应该是中午一点(阳光略偏)。但事实上他们指的是一定是同一个時间。
想像一下，假如下午十二点从英国伦敦给法国巴黎的好朋友打一个电话，他接听电话时手机表明的应该是中午一点。但不论是英国伦敦的下午十二点，或是大巴黎的中午一点，都仅仅同一个客观性時间的二种不一样表明罢了。这一与时区时间不相干的客观性時间，大家称作“时时刻刻”。实际上，在绝大多数情景下，大家需要关心的全是这一时时刻刻，而其余的時间，统统做为它的化合物或等价物。用这类客观性时时刻刻做为纪录时唯一的一种時间，可以防止许多的定义搞混。
6. GMT —— 格林威治国际标准时间
自打明确了时区时间以后，国际性上就把格林威治时间记作 GMT 0。针对同一个时时刻刻，可以有 12:00 GMT 00:00、13:00 GMT 01:00 等多种多样等额的的代表方式。
7. UTC —— 协调世界时
现代科学技术时间观念精密度的需求愈来愈高，GMT 借助天文学观察(地球的自转)获得的时间段早已远无法达到现代科学技术的精密度规定。因此大家改成原子钟来完成高精密记时，可是 GMT 早已有许多历史时间运用，立即把它换成原子钟记时会产生一些不兼容性问题。因此，大家建立了 UTC 時间，便于在新使用中替代 GMT。
因为 UTC 不会再借助天文学观察来获得，因此地球的自转一天的时间段也不会再一定相当于 86400 秒。假如地球的自转略微慢了一丢丢呢?那一天的最后一分钟很有可能就会有 61 秒，这称为闰秒。实际上，因为潮汛功效，地球自转的确一直在微不能查地降速。因此，假如在一些系统软件中见到 23:59:60 那样的表达方式，请不要急着喊 BUG，先看一下当初的新闻报道上是否有发表闰秒公示。
自然，为了更好地降低没必要的转换，UTC 在制定的情况下有意向 GMT 坚定理想信念，在绝大多数情景下，二者沒有特别注意的区别。
8. 日历
大家常常提及日期，但其实并没有一个称为日期的单独定义。全部的日期，实际上是在某一日历系统软件中的日期。例如大家既可以用“1911 年 10 月 10 日”表明产生武昌起义的日期，还可以用“宣统三年八月十九”表明。这两个都对。因此，在我们要把一个时间显示给客户的情况下，其日期一部分务必特定一个日历才可以恰当地恢复出厂设置。
大家日常采用的默认设置日历系统软件，全是指格里高利日历系统软件，因为采取它的我国较多，因而也被称作阳历。而我国的传统式农历历法称为阴历或农历。相近的，也有伊斯兰历和佛家历等日历系统软件。
而年、月、日、礼拜等，也全是与特殊日历系统软件密切有关的定义。因此，一旦碰到“下一个月”、“第 2 周”那样的定义，先要清楚它就是指阳历系统软件中的。
一些语言表达或其默认设置库文件把日期的定义绑死在了阳历系统软件上，例如 Java 的 Date 类，这会致使它在国际化时无法融入不一样的日历系统软件，非常容易造成搞混。因此 Date 类的一些方式 和特性被弃用，并在 Java 8 中导入了一些新的時间/日期类。
时间的表明文件格式
无论采用哪一种時间/日期系统软件，也无论他们写出哪些文件格式，身后所表示的全是时时刻刻。这一点差别十分关键，假如搞混了他们，在设计方案国际化运用时，便会深陷模棱两可。
1. Unix 时间格式(Time stamp)
当 Unix 系统软件问世的情况下，必须一种算法设计来表示时间，在计算机软件資源十分不足的情况下，系统软件的室内设计师挑选应用 32 位整数金额来表示时间，并以 UTC 時间的 1970年1月1日0时0分0秒 做为起始点。
伴随着 Unix 和 Linux 系统软件的普遍时兴，这类表达方式的运用范畴也越发广。殊不知，因为它是 32 位整数金额，因而它较多只有表明到 2038 今年初。但是，在新系统中，早已改成 64 位整数金额表明时间格式，它可以表明到2900亿光年以后，等同于不会有较大时间限制了。但充分考虑存有许多遗留下系统软件，这类转移将是一个较大的工程项目。
除开兼容问题以外，Unix 时间格式在调节、跟踪层面也很不友善，你难以一眼看得出它是啥時间，因此，在 API 和日志中最好不要再用这类文件格式传送或储存時间数据信息。
2. RFC2822
在互联网协议中传递的字符串数组，通常是 RFC2822 文件格式的。例如 Thu, 10 Dec 2020 13:49:45 GMT。这类方式尽管冗杂，但不会有精密度限定，因此在一些对储存空间不很比较敏感、但重视易读性的场所却很适合。
但是，这类文件格式涉及到一点英语，这对非英语国家的人不太友善。因而尽管对开发设计和调节的危害并不大，但在国际化运用中尽量不要把它立即展示给终端用户。
3. ISO8601 / RFC3339
另一种常见的字符串数组表达方式是 ISO8601 文件格式，例如 2020-12-01T00:49:45.001Z。
ISO8601 包括许多种子格式。实际上，我国采用的日期文件格式规范便是 ISO8601，但大家日常关键应用其“年-月-日”一部分。
从名称就可以看得出，它是一个 ISO 规范，几乎任何的当代语言表达和库都能有效地适用它，不容易导致模棱两可。并且，它只能应用阿拉伯数和两个字母，及其好多个可选择的分隔符，针对非英文客户较为友善。
在互联网技术行业，界定了另一个与 ISO8601 基本上兼容的规范 RFC3339，也就是“{年}-{月}-{日}T{时}:{分}:{秒}.{ms}{时区时间}”文件格式，在其中的年要用零补足为4位，月日时分秒则补齐为2位。ms一部分是供选择的。最终一部分是时区时间，前边事例中的 Z 实际上是零时区 Zulu 的简称，它也可能是 08:00 或 -08:00 等。
这两个规范十分类似，但又不彻底兼容，在程序编写情境下常见的 ISO8601，指的是一个像 RFC3339 一样五脏俱全的子版本号。也就是前边举例说明过的 2020-12-01T00:49:45.001Z 这类方式。
4. 人们可读文件格式(Human-readable)
尽管大家早已有很多种多样储存文件格式，但人们客户的市场需求是多种多样的，例如有时客户只期待见到“月-日”或時间中的其他一部分，乃至也有“刚、五分钟前、上月”等“人们友善文件格式”，这种信息内容显而易见不是全的，并且很不标准，没法做为储存文件格式应用。她们存在的价值，就取决于供人们阅读文章。
也有另一种非常容易弄混的人们可读文件格式，例如 2020-12-01 00:49:45.001，为什么说它是人们可读文件格式而不是 ISO8601 呢?问题的重要不取决于它少一个 T，而在于它丢失时区时间信息内容!这样一来，当我将这一时间给一位英国伦敦同学们看的情况下，大家默认设置都是会把它作为当地时间，看起来一样，但实际上的时刻差了整整八小时，啥事都拖延了!
与时间相关的程序编写关键点
1. 只储存时刻
Unix 时间戳、RFC2822 和 ISO8601 存储的全是时刻，而人们可读格式却非如此，因为它通常会缺乏尤为重要的时区信息内容。因此，不要在数据库查询中储存人们可读格式，而应当储存时刻，不然会遗失信息内容。仅有在把时间表明给人们的情况下，才应当临时性转化成人们可读格式。
2. 只传送时刻
在 API 中，大家只应当传送时刻。由于 API 的服务提供者和顾客很可能没有在同一个时区，假如传送缺乏时区的人们可读格式，便会被表述为分别时区的时间，进而产生模棱两可。
3. 恰当设定服务器时刻
在服务器的内部结构，储存时刻通常应用 Unix 时间戳，这代表它是 UTC 时刻。
如果你要在服务器上设定时间的情况下，通常会键入当地时间，而且由服务器内部结构转换为时刻后起效。这就规定服务器上务必恰当设定了你键入的当地时间所相应的时区，不然转换时便会出差错，让服务器所解释的时刻有别于你期待的时刻，进而产生不正确。
假如你应用远程登陆的形式去管理方法服务器，可以把现阶段对话的时区临时性设定给你所属的时区，那样就可以随意键入当地时间了，服务器会全自动帮你转换。自然，假如你需要以另一个时区的客户真实身份在服务器上查看，还可以把现阶段对话的时区设定为该消费者的时区，那样就可以随意应用该客户期待的时间了。
还可以选用另一种计划方案：把服务器设定为零时区，而且每一次对话时不会再设定时区。那样可以避免忘却，但你就需要自身把当地时间转换到零时区时间才可以在服务器上导入了。例如你需要查看北京市时间今日 00:0012:00 的日志，当在服务器上做维护保养的情况下就需要转换成服务器上(零时区)的时间也就是昨日16:00今日4:00。
这2种方法各有利弊，但无论使用哪一种计划方案，都需要记牢时区仅仅现象，真正时刻才算是压根。务必保证全部服务器上的真正时刻保持一致，那样才会纪录一个唯一的“实情”，以保持数据的一致性。例如，假如服务器设定为零时区，键入的时间时则是你的当地时间，显而易见会造成不正确。
让每个连接点的真正时刻保持一致并不易。但是好在互联网技术创建之初就制定了一个协议书：互联网时间协议书 NTP。它可以协助每个节点自动同步其真正时刻，在移动互联网上绝大多数地区，其同歩精密度可以做到 1~50 ms。
4. 最好是让上中下游服务器的时区保持一致
无论使用哪一种计划方案，都最好是保证上中下游服务器中间的时区保持一致，尤其是运用服务器与相对的数据库查询服务器。例如运用服务器和数据库查询服务器假如各自设置成了当地时区和零时区，而且在运用服务器上推送一条 SQL，以查看 2020-01-01 和 2020-01-02 中间的数据信息，那麼这一时刻究竟指的是什么呢?运用服务器认为它在查当地时区的，而数据库查询服务器认为它要查零时区的，这很明显是失误的。
在储存信息的情况下，这类问题更比较严重。假如一个表格中一些时间字段名是由运用服务器填好的，而另一些字段名是由数据库查询服务器填好的，那麼这类时区设定领域的差别就很有可能产生毁灭性的不正确。
为了更好地预防这类问题，非常简单的法子是让这种服务器的时区保持一致。假如没法保持一致应该怎么办呢?这就需要涉及到下面的一些关键点了。
5. 不必应用“日期”
刚刚提及的问题，其表层问题在时区，实质问题却取决于“日期”。这两个日期有哪些问题呢?问题就取决于它沒有内置时区信息内容!因此，运用服务器和数据库查询服务器中间，将没法就时区达成一致!各种信息内容遗失问题是许多 BUG 的根本原因，这儿一样如此。
更明显的是，它还遗失了时间信息内容。
即然我想传的是“日期”，为何还必须带时间信息内容呢?非常简单，由于没所说“日期”!大家日常常说的今日，实际上是个时间段，指的是本时区今日 00:00:00 到明日 00:00:00 中间。假如换一个时区，今日很有可能就并不是今日了，反而是从昨日 16:00:00 到 今日 16:00:00。如果你说的今日指的到底是哪一天呢?
因此，尽管和客户互动时，大家会应用日期的定义，可是在真实的流程中，大家应当一直应用时刻，那样才能够维持定义一致性。
6. 储存时应用来源于运用服务器的时刻
尽管可以让数据库查询服务器和运用服务器保持一致，但为了更好地简单化逻辑性，储存数据信息时，尽可能由运用服务器来给予时刻，而不必由数据库查询服务器给予，那样可以简单化时刻的由来，更易于维持一致性。
而针对手机客户端给予的时间，我们无法信赖，由于手机客户端连接点通常没有在大家的调节区域内，应用手机客户端数据信息会产生数据信息不正确，乃至产生网络安全问题。
因此，针对必须保留的数据信息，把运用服务器上的时刻做为实情之源通常是最好的选择。
7. 查看时应用来源于客户的时刻
查看通常是来源于客户角度的，例如当消费者在北京查询今日的数据信息时，他一般是期待查看北京市时间今日 00:00:00 到明日 00:00:00 中间的数据信息，而并不会关注服务器在哪儿。
因此，假如我们要设计方案一个查看今日数据信息的 API，那麼就不可以把一个日期发送给运用服务器，由于手机客户端和服务器端的时区很有可能不一样，服务器端就不能确切了解手机客户端的用意。大家应当发送给它2个主要参数：本时区今日的开始时刻和完毕时刻。
8. 应用“闭-开”区段表明时间段
在我们用时间段来表明日期的情况下，必须留意区段的右边应该是去心邻域，换句话说，查看要今日的信息就需要查看今日深夜零点到明日深夜零点中间的数据信息，但不包含明日深夜的零点。不然即使大家用 11:59:59.999 来查看，依然很有可能存有一条今日的数据信息发生在这个时间点以后。
用 SQL 在查数据库查询时有一个坑：BETWEEN 是个闭区间，换句话说其完毕时间是包括在汇总区域内的。因此，大家需要用 今夜零点 >= 时间 AND 时间 < 明天零点 才可以精确查出来今日的数据信息。
9. 强制性特定时区
有时，客户期待应用的时区并非自身所属的时区，例如当客户到其他时区外出时，很有可能关注的依然是自身原先的时区。除开让客户强制性改动手机客户端的时区以外，还能够容许现阶段客户特定一个时区，在运用服务器上放这一时区开展转换。但是，这样的事情下手机客户端必须对日期选择符开展特别解决，便于让客户认知的日期与具体采用的日期保持一致。
10. 特定数据库查询对话的时区
大家常常要依据年月日周等规范开展统计分析。此刻只根据特定区段就不易统计分析了。我们可以把数据库查询对话的时区改动为客户期待的时区。例如 alter session set time_zone = ‘ 08:00’;。这样一来，我们在 SQL 中采用的函数公式就能获得准确的年月日周等时区有关的結果了。
汇总
时间包括许多有关却又非常容易弄混的定义。尤其是人们的日常用词通常并不是很精准，这就留有了许多安全隐患。细心区别这种定义，而且在思索的情况下有意应用这种精准的定义，可以防止许多与时间相关的 BUG。
【文中是51CTO栏目创作者“ThoughtWorks”的原创设计文稿，微信公众平台：思特沃克，转截请联络创作者】
戳这儿，看该创作者大量好文章