我有一个API看起来像
/summary/yyyy/mm
- 返回所请求年份和月份的数据摘要。
- 其中一件事，如果这是当前年份和月份，则返回剩余天数。例如：
2013和10的days_left: 9以及服务器上的当前日期为21 Oct 2013
如何计算剩余天数？
这是在 python 中实现的
def current_financial_month_details(self):
time_from, time_to = self
.get_start_end_time_current_financial_month()
today = datetime.today()
from_time = datetime(year=today.year, month=today.month,
day=today.day)
return {
'time_from': time_from,
'time_to': time_to,
'remaining_days': (time_to - from_time).days
}
问题出在哪里？
- 服务器位于东海岸，客户端（带浏览器的我）位于太平洋时区
- 当太平洋标准时间晚上 9 点时，东海岸的时间会发生变化，所以如果我运行命中
/summary/2013/10并且如果在太平洋标准时间对我Oct 21 2013，那么 EST 的日期已经更改，所以days_left: 8客户端不正确。 对吧？
我该如何处理这种情况？
大多数人认为最佳做法是将日期和时间存储在独立于地理位置的时区中 - 最常见的是 UTC。如果您拥有将从具有不同时区的位置访问（或最终可以访问）的服务，则同样适用。
正如 J0HN 所提到的，客户端在与服务器交互时应该负责从 UTC 转换/转换为 UTC。在您的情况下，这意味着days_left应定义为当前 UTC 日期和月底（UTC）之间的天数。
特别是对于python，有两种类型的datetime.datetime对象：朴素对象和时区感知对象。朴素日期时间不附加任何时区信息，因此（在网络程序中）一个好的做法是仅对 UTC 时区中的时间使用朴素日期时间。要进行计算（例如，减去两个日期），请考虑使用 datetime.utcnow 而不是 datetime.now ，这样就可以避免任何与时区相关的问题，包括（但不限于）由 DST 引起的错误时间增量。
如果您确实需要处理其他时区（例如，用于向用户显示），则可能需要使用外部库，因为 python 本身不提供时区数据库。这个问题有关于这个问题的更多信息。
你有几个选择。
首先是指定交付结果的时区，并期望客户端接受这种差异。显而易见的选择是服务器时区或 UTC。
其次是让 API 也返回当前日期以及天数。它不会改变结果，但至少您将能够检测到日期与您预期的日期不同。
第三是让 API 输入时区，以便服务器可以调整其处理。
第四是在午夜以外的某个时间更改日期，例如凌晨 5 点。这仅在您的客户都处于相似的时区并且您的活动不是全天候时才有效;如果你在中国有一个客户，你可能会后悔这个选择。