mr-*_*-sk 5 python architecture datetime design-patterns system-design
我正在尝试确定(因为我的应用程序正在处理来自不同来源和不同时区、格式等的大量数据)如何最好地存储我的数据并使用它。
例如,我应该将所有内容存储为 UTC 吗?这意味着当我获取数据时,我需要确定它当前所在的时区,如果它不是 UTC,则进行必要的转换以使其如此。(注意,我在 EST)。
然后,在对数据执行计算时,我是否应该提取(假设它是 UTC)并进入我的时区 (EST),以便我查看它时有意义吗?我应该将其保留在 UTC 中并进行所有计算吗?
很多这些数据是时间序列,将被绘制成图表,图表将在 EST 中。
这是一个 Python 项目,所以假设我有一个数据结构:
"id1": {
"interval": 60, <-- seconds, subDict['interval']
"last": "2013-01-29 02:11:11.151996+00:00" <-- UTC, subDict['last']
},
Run Code Online (Sandbox Code Playgroud)
我需要对此进行操作,通过确定当前时间 (now()) 是否 > 最后一个 + 间隔(60 秒已经过去)?所以在代码中:
lastTime = dateutil.parser.parse(subDict['last'])
utcNow = datetime.datetime.utcnow().replace(tzinfo=tz.tzutc())
if lastTime + datetime.timedelta(seconds=subDict['interval']) < utcNow:
print "Time elapsed, do something!"
Run Code Online (Sandbox Code Playgroud)
那有意义吗?我在任何地方都使用 UTC,无论是存储还是计算......
另外,如果有人有关于如何在软件中使用时间戳的好文章的链接,我很乐意阅读它。可能像 Joel On Software 用于在应用程序中使用时间戳?
在我看来,你似乎已经在以“正确的方式”做事了。用户可能希望在本地时区(输入和输出)进行交互,但通常以 UTC 格式存储标准化日期,以便它们明确并简化计算。因此,请尽快标准化为 UTC,并尽可能晚地进行本地化。
有关 Python 和时区处理的一些少量信息可以在这里找到:
我当前的偏好是将日期作为 unix 时间戳tv_sec值存储在后端存储中,并datetime.datetime在处理过程中转换为 Python 对象。处理通常使用 UTC 时区的对象完成datetime,然后在输出之前转换为本地用户的时区。我发现拥有丰富的对象(例如 a)datetime.datetime有助于调试。
时区处理起来很麻烦,您可能需要根据具体情况确定是否值得付出努力来正确支持时区。
例如,假设您正在计算每日使用的带宽计数。可能出现的一些问题是: