我正在开发一个API，我只是想知道是否有人可以就以下情况提出建议。。。
我的Web服务器时间已设置为UTC，PHP时区已设置为使用UTC。数据库中的所有时间都保存为unix时间戳，每个用户都与他们的时区一起存储在数据库中。
现在我的问题是…API应该使用用户存储的时区并在发送之前调整时间戳，还是应该发送UTC时间戳并依赖于客户端在用户看到之前从API请求调整时区？
其他主要API如何处理时间戳？
我使用以下假设（用规范术语）：
API应提供UTC日期时间，如果需要，客户端/消费者应正确本地化。API应接受UTC日期时间，并可接受本地化日期时间进行设置。
我总是以以下格式提供UTC RFC3339 ISO时间戳：YYYY-MM-DD HH:MM:SSZ。API的响应可能如下：
{
'title' : 'Foo',
'due_date': '2011-12-13 12:00:00Z'
}
而我同时允许客户端指定可感知的日期时间。所以我允许以下内容：
http://api.example.com?title=Foo&due_date=2011-12-13 13:00:00+0100->转换为UTC并保存http://api.example-com?title=Foo&due_date=2011-12-13 12:00:00Z->UTC
您可以使用UNIX时间戳使用相同的假设（就我个人而言，我不想使用UNIX时间标记，因为它们的开始日期（1970年）和结束日期（2038年）有限）。
如果要保存最初指定的时区；你绝对应该把它单独存放，但要放在旁边。在我的头顶上有这样的东西：
{
'title' : 'Foo',
'due_date' : {
'utc': '2011-12-13 12:00:00Z',
'converted_from' : '2011-12-13 13:00:00+0100'
}
}
如果您更喜欢UNIX时间戳：
{
'title' : 'Foo',
'due_date' : {
'utc': 1326456000,
'original_offset' : 3600
}
}
这确实是一个非应答器，但使用对API有意义的东西。
许多服务，无论好坏，总是只在一个时区（主要是UTC）进行通信。如果这适用于应用程序，那就太好了。
但是，如果时区具有任何含义，那么不将该信息一起发送显然是错误的，无论是单独发送（例如带时区的日期字符串）还是分开发送（例如日期、时区）。