跨语言时区处理与Epoch

不念不忘少年蓝@ 2022-06-17 12:26 194阅读 0赞

# 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进行跨时区、跨语言交互时，处理与平常（无时区交互时）一致，无需任何特殊处理。若进行特殊处理，又处理不对应时，反倒会画蛇添足。

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