时区地狱
使用服务器端的 Python 渲染日期和时间来展示到用户的浏览器并非一个好主意。考虑如下的例子, 我在 2017 年 9 月 28 日下午 4 点 06 分写这篇文章。我身处的时区是 PDT(UTC-7),在 Python 解释器中运行如下:
>>> from datetime import datetime
>>> str(datetime.now())
'2017-09-28 16:06:30.439388'
>>> str(datetime.utcnow())
'2017-09-28 23:06:51.406499'
datetime.now() 调用返回我所处位置的本地时间,而 datetime.utcnow() 调用则返回 UTC 时区中的时间。 如果我可以让遍布世界不同地区的多人同时运行上面的代码,那么 datetime.now() 函数将为他们每个人返回不同的结果,但是无论位置如何, datetime.utcnow() 总是会返回同一时间。 那么你认为哪一个更适合用在一个很可能其用户遍布世界各地的 Web 应用中呢?
很明显,服务器必须管理一致且独立于位置的时间。 如果这个应用增长到在全世界不同地区都需要部署生产服务器的时候,我不希望每个服务器都在写入不同时区的时间戳到数据库,因为这会导致其无法正常地运行。 由于 UTC 是最常用的统一时区,并且在 datetime 类中也受到支持,因此我将会使用它。
但这种方法存在一个严重问题。 对处于不同时区的用户,如果他们看到的是 UTC 时区中的时间,那么很难确定是何时发布的信息。 他们需要事先知道展示的时间是 UTC 时区的,才能在精神上调整自己的时区。 设想一下 PDT 时区中的一个用户在下午 3 点发布了一些内容,并立即看到该帖子以 UTC 时间表示的晚上 10:00 或更准确的 22:00,这太混乱了。
从服务器的角度来说,将时间戳标准化为 UTC,意义重大,但这会为用户带来可用性问题。 本章的目标就是解决该问题,同时保持服务器中以 UTC 格式管理的所有时间戳。 While standardizing the timestamps to UTC makes a lot of sense from the server's perspective, this creates a usability problem for users. The goal of this chapter is to address this problem while keeping all the timestamps managed in the server in UTC.
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论