查看文档，查询API和推送API的签入对象中的数据在时区方面存在差异。
根据https://developer.foursquare.com/overview/realtime的示例推送将包含tz的名称，例如America/New_York
然而，根据https://developer.foursquare.com/docs/responses/checkin(和API资源管理器)一个签入对象将包含时区偏移例如60为GMT+1
我自己还没有确认推送API中的内容，因为我必须设置SSL证书，有人能确认文档是正确的吗?我们确实有两种tz格式。我本以为包括时区而不是偏移量会更好，因为它不像数字那样随夏令时而变化。欧洲/伦敦将始终是一个常量，因为偏移量将在0和60分钟之间切换
我并不直接熟悉FourSquare的API，所以我无法为你证实或否认这一点。但我可以告诉你，通常情况下你会同时使用这两种方法。
如果数据代表一个特定的时间，只显示偏移量是可以的。由于checkin响应提供了createdAt日期/时间，作为自epoch(又名"Unix时间戳")以来的整数秒数，因此提供单独的偏移量是合适的。(虽然我发现有趣的是，他们提供的偏移量作为一个字符串，而不是作为一个整数分钟数。)您可以这样做的另一种方式是使用单个DateTimeOffset值，通常以ISO8601格式表示，如2013-06-02T01:23:45-07:00。
但是您可能知道，偏移量并不是唯一地标识一个时区。在单个事件的情况下，不需要这样做。但是，如果它是一个反复出现的事件，或者如果您可能想要修改时间值，那么单独的偏移量是不够的。这时需要完整的区域标识符。
如果您有一个区域标识符，如America/New_York，那么您总是可以找到任何日期/时间的正确偏移量。但是并不是每个人都有现成的TZDB实现。例如，在Windows上的。net中，默认情况下你会得到微软笨拙的时区数据库，如果你想使用TZDB区域，你必须找到一个库(如NodaTime)。
对于相同类型的操作(签入)的push和pull会有不同的值，这似乎很奇怪，只是因为它们通过不同的api。我对Foursquare的建议有三点:
- 对同一活动的数据保持一致，无论推还是拉。
- 为提供TZDB标识符和与事件相关的UTC偏移量。
- 以单个值提供事件的时间戳和偏移量，作为ISO8601格式的字符串，而不是unix时间整数。
Foursquare文档是正确的，但有点不完整(截至发布时间)。签入响应包含一个timeZoneOffset字段。实时推送响应有一个timeZone字段和一个timeZoneOffset字段——timeZone字段出于遗留目的仍然存在。
谢谢你指出这一点;我们将更新文档，以反映timeZoneOffset是目前首选的方法。正如Matt所提到的，偏移量方法是从createdAt中识别特定时间的更好方法。