在checkin中的时区

Question

查看文档时，查询API的checkin对象中的数据与timeZone的推送API之间存在差异。

根据https://developer.foursquare.com/overview/realtime示例推送将包含tz的名称，例如America / New_York

但是根据https://developer.foursquare.com/docs/responses/checkin（以及API资源管理器），checkin对象将包含timeZone偏移量，例如60为GMT + 1

我自己还没有设法确认Push API中的内容，因为我要设置SSL证书，任何人都可以确认文档是否正确，我们确实有2种类型的tz格式。我原以为包括timeZone而不是偏移量会更好，因为与日期不同，这与夏令时不同。欧洲/伦敦将始终是一个常数，因为偏移将在0到60分钟之间切换

Answer 1

我不是直接熟悉FourSquare的API，所以我无法确认或否认这一点。但我可以告诉你，经常有两种情况都会使用。

如果数据表示特定时间，则只显示偏移量。由于签入响应提供createdAt日期/时间作为自纪元以来的整数秒（也称为“Unix时间戳”），因此提供单独的偏移是合适的。 （虽然我觉得有趣的是它们将偏移量作为字符串提供而不是整数分钟。）另一种方法是使用单个DateTimeOffset值，通常以ISO8601格式表示，如在2013-06-02T01:23:45-07:00。要么是可以接受的。

但是您可能知道，偏移量不能唯一标识时区。在单个事件的情况下，它不需要。但如果它是重复发生的事件，或者您可能想要修改时间值，那么仅靠偏移是不够的。那时你需要完整的区域标识符。

如果您有一个区域标识符，例如America/New_York，那么您始终可以找出任何日期/时间的正确偏移量。但不是每个人都有可用的TZDB实现。例如，在Windows上的.Net中，默认情况下，您将获得Microsoft笨拙的时区数据库，如果要使用TZDB区域，则必须找到一个库（如NodaTime）。

对于相同类型的操作（签入）的推送和拉动，由于它们通过不同的API而具有不同的值，这似乎很奇怪。我的建议（到Foursquare）将是三重的：

• 对于相同活动的数据保持一致，无论推拉与拉动。
• 提供两者 TZDB标识符以及与该事件关联的UTC偏移量。
• 将事件的时间戳和偏移量作为ISO8601格式的字符串提供给单个值，而不是unix时间整数。

Answer 2

Foursquare文档是正确的，但有点不完整（截至发布时）。签到响应包含timeZoneOffset字段。实时推送响应具有timeZone字段和一个timeZoneOffset字段 - timeZone字段仍然用于传统目的。

感谢您指出这一点;我们将更新文档以反映此时timeZoneOffset是首选方法。正如Matt所提到的，偏移方法是从createdAt识别特定时间的更好方法。