我们正在开发一个具有身份验证标头的API，其中必须处理时间戳。由于我们将来可能需要更多地使用时间戳，并希望在我们使用的时区内保持一致，因此我想知道API是否存在传统的时区。例如UTC + 0。
提前致谢
答案 0 :(得分：1)
在某些情况下，您会发现HTTP标头（例如标准Date标头）采用RFC5322格式（即RFC2822，RFC822）。例如：Tue, 31 Jan 2017 17:45:00 GMT
在Date标题中，时区缩写始终为"GMT"（相当于UTC用于此目的），即使RFC5322格式允许其他时区。
以上格式并不是首选，它只是我们一直坚持的东西。您当然可以使用您希望的任何格式为您自己的HTTP标头。
更好的格式是RFC3339 format。这类似于ISO8601扩展格式。一个例子是：2017-01-31T17:45:00Z。最后的Z表示＆＃34; Zulu＆＃34;时间，与GMT或UTC相同。但是，您也可以指定与UTC的时区偏移量，例如美国太平洋时区的等效当地时间：2017-01-31T09:45:00-08:00
如果你有像1485884700这样的Unix时间码，那么时区总是 UTC。然而，这不是一个好的交换格式，因为它不是人类可读的，并且没有提供使用什么纪元或精度的上下文。人们必须从外部了解这些事情。它不适合HTTP标头，也不适合XML或JSON。
如果您正在讨论XML / JSON请求的主体，那么您应该只使用ISO8601。人们使用其他一些格式，但不推荐使用它们。
关于你应该使用什么时区 - 这完全取决于背景。如果您正在时间戳 - 您需要当前时间并记录它，那么您确实可以使用UTC。我认为出于授权目的，这是合理的。您也可以在当地时间工作，只要您提供与UTC的偏移量，这样就没有歧义。
但是，您（在评论中）说您的数据包含有关职位空缺的信息。这听起来像是你在谈论未来的时间 - 这是＆＃34;总是UTC＆＃34;规则。无论您何时谈论未来的时间，您都需要以最直接的形式表达本地时间，并且您还需要提供标识符（而不是偏移量）适用的时区。
例如，如果我在谈论职位空缺，我可以在我的数据中说：
{
"job": "dishwasher",
"available: "2017-02-13",
"start": "08:00",
"end": "16:00",
"tz": "America/New_York"
}
这些值将遵循ISO8601格式，仅限日期和仅限时间（或者如果我想将它们组合2017-02-13T08:00） - 并且不会指定时区。相反，IANA时区标识符America/New_York（美国东部时间）在单独的字段中提供。
这很重要，因为这项工作可能会持续到未来几个月。 3月12日，美国东部时区将从UTC-5变为UTC-4。因此，不能指定单个偏移量，也不能使用UTC。
此外，即使是一次性事件，请记住，有些国家/地区会继续改变他们对时区和DST规则的看法，这就是为什么每年tz database都会有数十次更新的原因。如果您计算未来某个日期和时间的偏移量，那么当它转过来时，您可能会发现政府已经更改了偏移量。