我们正在开发一个API，它有一个身份验证头，其中必须处理时间戳。由于我们将来可能需要更多地使用时间戳，并且希望使用的时区保持一致，我想知道API是否有一个传统的时区。例如UTC+0。
提前感谢
在某些情况下，您会发现HTTP标头(例如标准Date标头)是RFC5322格式(也称为RFC2822、RFC822)。例如：Tue, 31 Jan 2017 17:45:00 GMT
在Date报头中，时区缩写始终是"GMT"(为此，它相当于UTC)，即使RFC5322格式允许其他时区。
上面的格式并不是我们真正喜欢的，它只是我们一直坚持的东西。当然，您可以为自己的HTTP头使用任何格式。
一种更好的格式是RFC3339格式。这类似于ISO8601扩展格式。例如：2017-01-31T17:45:00Z。末尾的CCD_ 6指示"；祖鲁"；时间，与GMT或UTC相同。但是，您也可以指定与UTC的时区偏移，例如美国太平洋时区的等效本地时间：2017-01-31T09:45:00-08:00
如果您有像1485884700这样的Unix时间号，则时区为始终UTC。然而，这不是一个好的交换格式，因为它不是人类可读的，并且没有提供使用什么历元或精度的上下文。人们必须从外部了解这些事情。它既不适合HTTP头，也不适合XML或JSON。
如果您谈论的是XML/JSON请求的主体，那么您应该只使用ISO8601。人们还可以使用一些其他格式，但不推荐使用。
关于你应该使用什么时区，这完全取决于上下文。如果您在时间戳中获取当前时间并进行记录，那么您实际上可以使用UTC。我认为出于授权的目的，这是合理的。您也可以在当地时间工作，只要您提供与UTC的偏移量，这样就不会有歧义。
然而，你(在评论中)说，你的数据包含有关职位空缺的信息。在我看来，这听起来像是在谈论未来的时间——这是"；总是UTC"；规则无论何时您在谈论未来的时间，都需要以最直接的形式用当地时间来表达，还需要提供适用时区的标识符(而不是偏移量)。
例如，如果我谈论的是一个职位空缺，我可能会在我的数据中说：
{
"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。
此外，即使是一次，也要记住，一些国家继续改变他们对时区和夏令时规则的看法，这就是为什么每年都会对tz数据库进行数十次更新。如果你要计算未来某个日期和时间的偏移量，当它滚动时，你可能会发现政府已经更改了偏移量。