跨语言时区处理与Epoch

国际化通用程序或标准协议通常都涉及到时区问题，比如最近项目用到的OIDC（OpenID Connect）。

OIDC基于OAuth2协议，其id_token中包含了exp来表达该Token的过期时间，值为Unix Epoch（Timestamp，时间戳），通常各语言的日期实现会将该时间戳转换为本地日期，然后进行日期的比较。

0 时区与Unix Epoch

0.1 时区

为了统一地球上各地区的时间，建立了世界时，格林威治标准时间即作为第一个标准时间。地球以格林威治子午线为标准即0时区，按经度划分为24时区，东半球早于标准时间为正时区，西半球晚于标准时间为负时区。中国采用北京时间即正8区。格林威治标准时间缩写为GMT，东8区用GMT+08:00表示，即格林威治子午线的时间加上8小时为北京当地时间。

随着计时精度要求的提高，出现了原子计时器，形成了新的世界时，又称世界协调时简写UTC，就日常生活需求GMT与UTC等同。同时时区的划分也是一致的，北京时区用UTC+08:00表示。

0.2 Unix Epoch

在Unix系统上，为了用一个整数表示具体的时间，以1970年1月1日0时0分0秒0为基准, 将经过的秒数记为一个数值，然后用该数值表示某个时间。比如时间戳3600即表示1970年1月1日1时0分0秒，也就是在基准时间上经过了3600秒。由于时区问题，对于UTC+00:00时区的1970年1月1日0时0分0秒0时间点，实际为北京当地时间的1970年1月1日8时0分0秒0,这样对于时间戳3600即为北京当地时间的1970年1月1日9时0分0秒0 表示为 1970-01-01 09:00:00+08:00。

0.3 时间表示

时间表示一般分为带时区信息的、不带时区的、Unix Epoch。不带时区的日期串称为Naive Date,如1970-01-01 09:00:00。在日常生活中特指当地时间，在程序语言中有的没有特指，就是时区缺失，可以加上时区信息，有的语言默认为操作系统默认时区。

下面以Python和golang为例, 进行API操作描述

1 Python 时区操作

1.0 使用模块

import time
from datetime import datetime, timezone, timedelta
# 下面dateutil 可用，可不用
from dateutil import tz # 该package需要安装, pip install dateutil

1.1 当前时间

# Python 的datetime模块提供了两个函数来返回时间
naive_now = datetime.now() # 返回一个naive，本地时区的时间
# 如在世界时2017-04-25 10:00:03+00:00在北京时区的机器上执行该代码
# 返回 datetime(2017,4,25,18,0,3) # 还有微妙部分,假设为0，省略
naive_utcnow = datetime.utcnow() # 返回一个naive，UTC+0:00 <简写UTC>的时间
# 即返回 datetime(2017,4,25,10,0,3) # 微妙同上

1.2 有时区的时间

# 方法一：通过解析获取
china_date = datetime.strptime('2017-04-25 18:00:03+0800', '%Y-%m-%d %H:%M:%S%z')
# 返回 datetime(2017, 4, 25, 18, 0, 3, tzinfo=datetime.timezone(datetime.timedelta(0, 28800)))
# 可以看到返回的日期上tzinfo不为None了
# 当解析的日期不带时区时，返回的日期对象tzinfo为None即naive日期对象
naive_date = datetime.strptime('2017-04-25 18:00:03', '%Y-%m-%d %H:%M:%S')
naive_utcdate = datetime.strptime('2017-04-25 10:00:03', '%Y-%m-%d %H:%M:%S')
# 当naive日期与带时区的日期对象比较时，即使年月日时分秒以及微妙一致也是不相等的（因为时区不同）
# 即naive_date != china_date
# 两个naive的对象可以正常比较，两个非naive的对象也可以正常比较
# 方法二：强制设置naive日期对象的时区
tz_utcdate = naive_utcdate.replace(tzinfo=timezone.utc)
# 返回 datetime(2017, 4, 25, 10, 0, 3, tzinfo=datetime.timezone.utc)
# 该方法强制替换某个时间(日期)对象的时区属性即使是非naive的，并生成新的一个日期对象

1.3 获取时区

#通过安装dateutil这个Package
# 获取 当前系统时区，第一个参数为name，可以任意设置
TZCUR = tz.tzoffset('current', -time.timezone) # 注意 time.timezone 与时区正负号相反, 用秒表示
# 或者
TZCUR = timezone(timedelta(minutes=-time.timezone/60)) # 作为timezone的参数，timedelta的参数最好用hours或minutes
# 获取 UTC 时区
TZUTC = timezone.utc
# +8:00 时区/ China
TZCHINA = tz.tzoffset('UTC+8:00', 8*3600)
# 或
TZCHINA = timezone(timedelta(hours=8), 'UTC+08:00') # 第二个参数为name可以为空或不传
# +9:00 时区/ Japan
TZJAPAN = tz.tzoffset('UTC+9:00', 9*3600)
# 或
TZJAPAN = timezone(timedelta(hours=9), 'UTC+09:00')

1.4 转换时区

将某个时区的日期转换为另一个时区的日期，如北京时间的晚18点，转换为东京时间，即为晚19点。

# 使用astimezone函数，转换带时区的日期对象的时区
japan_date = china_date.astimezone(TZJAPAN)
# 返回 datetime(2017, 4, 25, 19, 0, 3, 0, tzinfo=tzoffset('UTC+9:00', 32400)
# 对于naive的日期对象，即tzinfo属性为None时，该方法无法进行日期转换，抛出异常
# 也就是 datetime.now()或datetime.utcnow()的结果都无法执行astimezone方法

1.5 Epoch 的 生成

# 在Python3中datetime对象可以直接执行timestamp方法,如
epoch = naive_date.timestamp()
# 返回 1493114403.0 # 假设naive_date的微妙为0
# 即该epoch表示从基准时间开始，经过1493114403秒
# 对于没有时区信息的naive_date，默认使用系统时区
# 即datetime(2017,4,25,18,0,3)当作datetime(2017,4,25,18,0,3,tzinfo=tzoffset('UTC+8:00', 28800))处理，对应世界时为2017-04-25 10:00:03+00:00，距离基准1970-01-01 00:00:00+00:00为1493114403秒。
# 因此尽管naive_date 与 china_date对象不等,但执行timestamp方法后的结果一样
# 而且 china_date通过astimezone方法转换为其他时区的对象后执行timestamp方法得到的结果也一样
# 所以 datetime.now().timestamp() 与 datetime.utcnow().timestamp() 在非+00:00时区执行时不相等，因为两者实际是不同的时区，但由于缺失时区信息，强制按系统默认时区处理，两者将差time.timezone

1.6 按Epoch计算日期

# 同now函数一样，Python提供了两个函数生成本地和世界时日期
# 同样也是生成naive的日期，对象的时区属性为None
naive_date_from_epoch = datetime.fromtimestamp(1493114403)
naive_utcdate_from_epoch = datetime.utcfromtimestamp(1493114403)
# 尽管两个epoch数值一样，得到naive日期对象将差8小时（若系统默认时区为+08:00）
# 由于返回结果为naive日期，因此两个结果比较是不相等的，执行timestamp得到的数值也不相同
# 将naive对象分别设置正确的时区后，两者将一直
local_date_from_epoch = naive_date_from_epoch.replace(tzinfo=TZCUR) # 系统时区
utc_date_from_epoch = naive_utcdate_from_epoch.replace(tzinfo=TZUTC) # UTC+0时区
# 此时 local_date_from_epoch == utc_date_from_epoch
# 两者生成的Epoch也都是1493114403
# Epoch 为1时，可以更好的看到该情况
datetime.utcfromtimestamp(1) # 返回 datetime(1970, 1, 1, 0, 0, 1)
datetime.fromtimestamp(1) # 返回 datetime(1970, 1, 1, 8, 0, 1)
由于naive日期 datetime(1970, 1, 1, 0, 0, 1) 执行timestamp方法，将系统时区处理即按1970-01-01 00:00:01+0800处理时（对应1969-12-31 16:00:01+0000）在Epoch的基准线之前，Python3.5的版本会抛出OverflowError的异常

1.7 跨编程语言

// golang 内置time模块进行日期相关处理
// A 获取当前时间
now = time.Now() // 与Python不同,返回的是一个带时区的'日期'对象
// golang使用time.Date传入年月日，时分秒，微妙去构造一个日期对象, 还必须传入时区信息，如
time.Date(2017, time.April, 25, 18, 0, 3, 0, time.Local)
// B 时区转换
now.UTC() // 转换为 UTC时间，即UTC+0时区时间
// C 按日期生成Epoch
now.Unix() // 生成到秒,返回整数
// 其中 now.Unix() == now.UTC().Unix() ，与Python一致
// D 按Epoch计算日期
time.Unix(seconds, microseconds) // 返回一个带时区的'日期'对象
// 以上两个日期对象都带本地时区
// 也就是 golang的 time.Unix等同于python的datetime.fromtimestamp(seconds).replace(tzinfo=TZCUR)
// 采用系统时区，基本是各语言的默认行为

2 总结

在进行跨时区处理时，只要正确区分naive日期对象和带时区的日期对象，基本就保证了时间处理的正确性，而Epoch值表示相对于基准时间的差值，有效的回避了该问题（不同时区基准naive不一样）。避免了传递不带日期的时间字符串的时区问题。

以Token过期为例，北京时间2017-04-25 18:00:03生成一个Token，一小时后过期，即北京时间2017-04-25 19:00:03过期。该Token传给东京的服务器后，按东京当地时间应该在东京2017-04-25 20:00:03时过期。

交互时传递参数为2017-04-25 19:00:03+0800时，由于带有时区信息可以准确表达，若缺失时区如2017-04-25 19:00:03时，双方都没有处理时会出错。

若用Epoch表示，Token生成时间为北京时间2017-04-25 18:00:03对应Epoch值为1493114403（即距离基准北京时间1970-01-01 08:00:00 相隔1493114403秒），Token过期时间为北京时间2017-04-25 19:00:03对应Epoch为1493118003（即生成时间之后3600秒）。 传递该Epoch值至东京服务器，收到后，解释为东京基准时间起之后1493118003秒的那个时间点该Token过期，自然就对应东京时间2017-04-25 20:00:03了。此过程，无需时区处理。

也就是说Epoch 1对应

• 1970-01-01 00:00:01+0000(UTC)
• 1970-01-01 08:00:01+0800(北京当地时间)
• 1970-01-01 09:00:01+0900(东京当地时间)

而Epoch 1493118003对应

• 2017-04-25 11:00:03+0000(UTC)
• 2017-04-25 19:00:03+0800(北京)
• 2017-04-25 20:00:03+0900(东京)

这样使用Epoch进行跨时区、跨语言交互时，处理与平常（无时区交互时）一致，无需任何特殊处理。若进行特殊处理，又处理不对应时，反倒会画蛇添足。

当采用的框架提供修改时区的功能是，可能会导致与语言默认行为不一致，此时要特别注意。