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进行跨时区、跨语言交互时,处理与平常(无时区交互时)一致,无需任何特殊处理。若进行特殊处理,又处理不对应时,反倒会画蛇添足。
当采用的框架提供修改时区的功能是,可能会导致与语言默认行为不一致,此时要特别注意。