设计 - 如何处理时间戳(存储)以及何时执行计算;Python

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 用于在应用程序中使用时间戳?

Aus*_*ips 3

在我看来,你似乎已经在以“正确的方式”做事了。用户可能希望在本地时区(输入和输出)进行交互,但通常以 UTC 格式存储标准化日期,以便它们明确并简化计算。因此,请尽快标准化为 UTC,并尽可能晚地进行本地化。

有关 Python 和时区处理的一些少量信息可以在这里找到:

我当前的偏好是将日期作为 unix 时间戳tv_sec值存储在后端存储中,并datetime.datetime在处理过程中转换为 Python 对象。处理通常使用 UTC 时区的对象完成datetime,然后在输出之前转换为本地用户的时区。我发现拥有丰富的对象(例如 a)datetime.datetime有助于调试。

时区处理起来很麻烦,您可能需要根据具体情况确定是否值得付出努力来正确支持时区。

例如,假设您正在计算每日使用的带宽计数。可能出现的一些问题是:

  1. 夏令时边界上会发生什么?为了便于计算,您是否应该假设一天始终为 24 小时,还是需要始终检查每天的计算,以确定一天在夏令时边界上可能有更少或更多的时间?
  2. 当呈现本地时间时,时间是否重复有影响吗?例如。如果您有一个以当地时间显示的每小时报告,但没有附加时区,用户是否会因为缺少一小时的数据或在夏令时更改期间重复出现一小时的数据而感到困惑。