REST API是否应该能够将日期时间转换为适当的客户端时区？

10

在实施我们的API时，出现了日期时间和时区的问题。

所有日期均已标准化为数据库中的UTC。当前，在非API应用程序中，所有日期时间都是根据用户的偏好设置先转换后才呈现。

现在，对API提出了同样的问题：API是否应该能够基于请求语义返回适合时区的datetime？

例如GET /posts?timezone=America/Sao_Paulo？

还是应该在正在访问API的任何客户端上完成此操作？

更新：因为它出现了几次：当前返回带有时区的时间戳（尽管始终为TZ offset +00:00）。格式是流行的8601：2015-10-29T23:00:49+00:00

rest api time

— 标记
source

如果返回包含时区的时间戳，则客户端可以轻松地将其转换为本地所需的任何时间。无论如何，这个问题似乎与REST无关。您可以采用多种方式来实现这一点，而不会违反REST的原理。请注意，公开此参数意味着您需要做更多的工作。在真正的RESTful架构中，您需要使这些链接以某种方式可发现。在客户端和服务器端实现不必要的复杂工作使我感到震惊。

— toniedzwiedz 2015年

>在客户端和服务器端实现这是不必要的复杂事情。感谢您的输入！

— 标记

17

您应该返回一个绝对时间点，然后任何人都可以根据需要本地化该时间戳记。“绝对时间戳”是指UNIX时间戳或人类可读的时间戳，其中包括标准ISO格式之一的时区，例如“ 2007-04-05T14：30Z”。客户端可以根据需要将其转换为本地时区。

如果您想接受时区参数并将时间戳本地化为该时区，那很好，但是您仍然应该使用绝对时间戳incl。您的响应中的时区，例如“ 2007-04-05T16：30-02：00”。鉴于此值与以前的非本地化值相同，因此为什么要提供此参数很麻烦，这是非常可疑的。时间戳记的确切显示格式最终取决于客户端的前端，因此无论如何都可能会对值进行后处理。

— 降低
source

4

“你为什么要去解决这个问题是很可疑的”-如果没有别的，那只是楔子的薄弱环节。该API的下一个客户端可能会要求您让他们指定strftime格式（加上月/日名称的区域设置），其便利原因与第一个客户端发现指定时区有用。即使将时区作为唯一的让步，您也使API的响应变得更加复杂：它不再只是“每次都以相同格式的时间戳记”，而是“以要求我表达的方式表达的时间戳记”

— Steve Jessop

3

确实，复杂。复杂性是邪恶的。它使每个人都更加努力地工作，而没有为产品或业务增加任何价值。千纸鹤致死。

— 布兰登

2

>您应该返回一个绝对时间点，我已经澄清了我已经在做这个问题。感谢您的见解！

— 标记

4

如果您已经具有将日期时间值转换为用户本地时区的逻辑，则可以在API中提供两种可能性。

如果客户发出类似的请求GET /posts，那么他们将获得所有默认时间（UTC）的时间。
如果客户提出类似的请求GET /posts?timezone=America/Sao_Paul，则回复中的所有时间都将调整为指定的时区。

然后取决于客户端实现他们想要对时区执行什么操作。

— 巴特·范·恩根·舍瑙
source

2

通常，您会期望从API获得UTC。

但是，如果您的“ REST API”只是使用javascript框架的网页的服务器端部分。我认为实际上您正在返回ViewModel，因此它应包含本地化的字符串，数字和时间。

— 伊万
source

2

这是一个坏，坏，坏的主意。考虑客户端存储来自服务器的响应，然后用户前往另一个时区的情况。现在，您遇到这种“功能”充其量不会给您带来任何好处或带来巨大麻烦的情况。

顺便说一句。您要测试多少个时区和多少个客户？如果服务器给出了对America / Sao_Paul的预期答复，它将对America / Sao_Paulo做出什么响应？

— gnasher729
source

我个人认为这是一个错误，我将其更正为America/Sao_Paulo。我想讨论一下如果无法确定时区会发生什么？要么是因为这完全是错误的，要么是因为TZ数据库已过时（我发现后者不太可能用作实际名称（但对于偏移值而言并非如此））。但是，无论哪种情况，我都可能会返回400 BAD_REQUEST响应。

— 将