1

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

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

然而，根据https://developer.foursquare.com/docs/responses/checkin（和 API 资源管理器），签入对象将包含时区偏移量，例如 60 表示 GMT+1

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

4

2 回答 2

0

我对 FourSquare 的 API 并不直接熟悉，因此我无法为您确认或否认这一点。但我可以告诉你，通常情况下你会同时使用两者。

如果数据代表特定时间，则可以仅显示偏移量。由于签入响应以createdAt自纪元以​​来的整数秒数形式提供日期/时间（又名“Unix 时间戳”），因此提供单独的偏移量是合适的。（尽管我发现它们以字符串而不是整数分钟数的形式提供偏移量很有趣。）另一种方法是使用单个DateTimeOffset值，通常以 ISO8601 格式显示，如2013-06-02T01:23:45-07:00. 两者都可以接受。

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

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

对于相同类型的操作（签到）的推送和拉取会因为它们通过不同的 API 而具有不同的值，这看起来确实很奇怪。我的建议（对 Foursquare）将是三重的：

  • 无论是推还是拉，都要对同一活动的数据保持一致。
  • 提供TZDB标识符和与事件关联的 UTC 偏移量。
  • 在单个值中提供事件的时间戳和偏移量，作为 ISO8601 格式的字符串，而不是 unix 时间整数。
于 2013-06-02T04:26:53.887 回答
0

Foursquare 文档是正确的，但有点不完整（截至发帖时）。签入响应包含一个timeZoneOffset字段。实时推送响应有一个timeZone字段和一个timeZoneOffset字段——该timeZone字段仍然存在用于遗留目的。

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

于 2013-06-03T19:58:32.907 回答