指定夏令时的REST API标准/最佳实践

Question

但是，有一种情况是，指定的时间落在该时区的夏令时内。在上述时区中，从4月到10月遵循夏令时，偏移量为(+10.30)。那么，如果我必须获得9月份的数据，客户是否应该提供基于日期的必要的偏移（2月的日期为+9.30，9月的日期为+10.30)？

或者客户端是否应该以当前时区的偏移量发送日期（不受日光影响），服务器是否应该负责识别夏令时的日期，并在处理之前将该日期标准化一小时？怎样处理这样的案件才是适当的呢？好心帮忙。

Answer 1

一般而言，我认为这些建议是好的：

• 不要使用偏移量，使用Olson ID。所以返回的时间应该包括澳大利亚/阿德莱德，而不是+9.30。任何有价值的日期库都可以理解Australia/Adelaide
• 如果您正在处理过去发生的事情，通常只使用UTC更容易。您的服务器可以对所有这些使用UTC，只需在查看之前让客户端处理到本地时区的转换。但这往往最好在应用程序的视图/表示层中处理，而不是在数据模型中处理。一个很有帮助的例子是，“1:30am”在我们过渡到冬季的晚上会出现两次。
• 对于将来“计划”的任何内容，通常最好使用“本地时间”+时区标识符。例如，如果您想在一年中的每一天下午2点做一些事情，您将需要知道它在什么时区中，以便根据DST的变化进行调整。对于世界上的一些国家，DST规则每年都会更改，因此这使您的系统成为未来的证明。

所以如果你预定明年与某人会面，在特定的（当地）时间。现在还不能百分之百保证是哪一个UTC时间，因为本地时间规则可能会导致移动。大多数国家的时区规则都相当稳定，但肯定不是全部。