如何从Twitter API可靠地确定用户的时区？ [英] How to reliably determine time zone for a user from the Twitter API?

问题描述

从Twitter的API获取用户信息时，他们会提供两个与用户时区相关的字段：

When getting information from Twitter's API for a user, they provide two fields related to the user's time zone:

utc_offset: -14400,
time_zone: "Indiana (East)"

不幸的是，这不是讲完整的故事，因为我不知道UTC偏移是在标准时间还是夏令时计算的。除以3600秒后，我得到-4小时，这在夏季是有效的，但是在冬天，正确的值是-5小时。

Unfortunately, this doesn't tell the full story because I don't know if that UTC offset was calculated during standard time or daylight savings time. After dividing by 3600 seconds, I get -4 hours, which is valid during the summer months, but in the winter the correct value would be -5 hours.

如果该值始终由夏时制确定，那么我可以为此编写算法，但是在对该主题进行一些搜索后，我看到了一些粘贴的输出这与该假设相反。 （举个简单的例子，此问题显示他/她的偏移量为-21600，然后他/她说他/她位于中央时间，如果在夏令时期间计算则为-18000）。

If the value was ALWAYS determined by the daylight savings time value then I could write an algorithm for that, however after some searching on the subject I've seen several pasted outputs that contradict that assumption. (as a quick example, this question shows his/her offset as -21600 and then he/she says he/she is on central time, which if calculated during daylight savings time would be -18000).

对我来说有意义的是，该值将从1月1日开始计算，我在网上发现的一些粘贴输出属于该类别，但是我自己的Twitter帐户显示了上面列出的值，对此假设无效。我下一个想法可能是它是在我创建帐户时计算出来的，但那似乎也是错误的，因为我可以在以后的任何时间更改时区（即使如此，我会在11月创建帐户时在标准时间而不是白天！）。

It would make sense to me that the value would be calculated as of Jan 1 and the several pasted outputs I've found online fall into that category, but my own Twitter account shows the values listed above for which this assumption is invalid. My next thought was maybe it was calculated at the time I created my account, but then that seems erroneous as well because I can change my time zone at any later point (and even so, I created my account in November when I would have been on standard and not daylight time!).

我最后的想法是，该值可能是在API请求的日期之前计算出来的。这很有道理，我所有的Twitter帐户似乎都证明了这一点。但是，我之前链接的SA问题表明该人在6月2日回答了该问题，即夏时制，他/她的值-21600反映的是中央时区的标准时间。

My last thought was that maybe the value is being calculated by the date of the API request. This makes a lot of sense and the Twitter accounts I own all seem to validate this. BUT, the SA question I linked to earlier shows that the person answered the question on June 2nd, which is daylight savings time and his/her value of -21600 reflects a standard time for the Central time zone.

有人解决了这个问题吗？非常感谢！

Anyone out there solve this problem? Thanks so much!

推荐答案

Twitter的前端使用Ruby on Rails。如果您使用自己的Twitter帐户设置，并查看时区的可能选项（在下拉列表中查看源代码），则会发现它们与 ActiveSupport :: TimeZone 提供的选项匹配。 code>，显示在本文档中。尽管Rails似乎理解了某些区域，但Twitter已忽略了该区域，但所有Twitter区域的键名都在该列表中。

Twitter's front end uses Ruby on Rails. If you go to your own twitter account settings and look at the possible options for time zones (view source on the dropdown list), you will find that they match up with those provided by ActiveSupport::TimeZone, shown in this documentation. Although there appears to be some zones understood by Rails that Twitter has omitted, all of the Twitter zone key names are in that list.

我已要求Twitter在将来，在此开发者请求中。

I have asked Twitter to use standard time zone names in the future, in this developer request.

Rails为什么限制此列表并使用自己的键值？谁知道。我之前曾问过，却很少得到回应。 在此处阅读。

Why does Rails limit this list and use their own key values? Who knows. I have asked before, and gotten very little response. Read here.

但是您当然可以使用其映射字典将 time_zone 值转换为标准IANA时区标识符。例如：

But you can certainly use their mapping dictionary to turn the time_zone value into a standard IANA time zone identifier. For example:

• 印第安纳州（东部） => 美国/印第安纳州/印第安纳波利斯


• 中部时间（美国和加拿大） => 美国/芝加哥

• "Indiana (East)" => "America/Indiana/Indianapolis"
• "Central Time (US & Canada)" => "America/Chicago"

这可以在轨道文档，并在源代码。 （向下滚动到 MAPPING 。）

This can be found in the Rails documentation, and in the source code. (Scroll down to MAPPING.)

然后，您可以使用所需的任何标准IANA / Olson / TZDB实现。它们几乎适用于每种语言和平台。有关更多详细信息，请参见时区标签Wiki 。如果您需要有关特定实施的帮助，则需要扩展问题以告诉我们您使用的是哪种语言以及到目前为止所尝试的内容。 （或考虑就该部分内容提出一个新问题。）

Then you can use any standard IANA/Olson/TZDB implementation you wish. They exist for just about every language and platform. For further details, see the timezone tag wiki. If you need help with a specific implementation, you'll need to expand your question to tell us what language you are using and what you have tried so far. (Or consider asking a new question about just that part of it.)

关于 utc_offset 字段，twitter不会发出明确他们使用什么基础进行计算。我的猜测是它是用户的当前偏移量，基于您调用API的时间。

In regards to the utc_offset field, twitter does not make it clear what basis they use to calculate it. My guess is that it is the user's current offset, based on the time that you call the API.

更新1

我在 TimeZoneConverter 库。如果您使用的是.NET，则可以使用该库简化转换并更轻松地掌握更新。

I have added support for converting Rails time zone names to both IANA and Windows standard time zone identifiers in my TimeZoneConverter library for .NET. If you are using .NET, you can use this library to simplify your conversions and stay on top of updates more easily.

更新2

Twitter的API 现在以以下格式返回时区：

Twitter's API now returns the time zone in this format:

"time_zone": {
    "name": "Pacific Time (US & Canada)",
    "tzinfo_name": "America/Los_Angeles",
    "utc_offset": -28800
},

使用 tzinfo_name 字段。做完了：）

这篇关于如何从Twitter API可靠地确定用户的时区？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！