获取当地时区的 Olson TZ 名称?
如何获取对应于的奥尔森时区名称(例如Australia/Sydney
) C 的 localtime
调用给出的值?
这是通过 TZ
、符号链接 /etc/localtime
或在时间相关的系统配置文件中设置 TIMEZONE
变量覆盖的值。
How do I get the Olson timezone name (such as Australia/Sydney
) corresponding to the value given by C's localtime
call?
This is the value overridden via TZ
, by symlinking /etc/localtime
, or setting a TIMEZONE
variable in time-related system configuration files.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(11)
我知道这是一种作弊,但是从
'/etc/localtime'
获取对您不起作用?就像下面这样:
希望有帮助。
编辑:我喜欢@AH的想法,以防
'/etc/localtime'
不是符号链接。将其翻译成 Python:This is kind of cheating, I know, but getting from
'/etc/localtime'
doesn't work for you?Like following:
Hope it helps.
Edit: I liked @A.H.'s idea, in case
'/etc/localtime'
isn't a symlink. Translating that into Python:我认为最好的办法是遍历所有 pytz 时区并检查哪一个与本地时区匹配,每个 pytz 时区对象包含有关 utcoffset 和 tzname 的信息,如 CDT、EST,有关本地时间的相同信息可以从 time.timezone/ 获得altzone 和
time.tzname
,我认为这足以正确匹配 pytz 数据库中的本地时区,例如输出:
在生产中,您可以预先创建这样的映射并保存它,而不是始终迭代。
更改时区后测试脚本:
I think best bet is to go thru all pytz timezones and check which one matches local timezone, each pytz timezone object contains info about utcoffset and tzname like CDT, EST, same info about local time can be obtained from
time.timezone/altzone
andtime.tzname
, and I think that is enough to correctly match local timezone in pytz database e.g.output:
In production you can create such a mapping beforehand and save it instead of iterating always.
Testing script after changing timezone:
一个问题是有多个“漂亮的名字”,例如“Australia/Sydney”,它们指向同一时区(例如 CST)。
因此,您需要获取当地时区的所有可能名称,然后选择您喜欢的名称。
例如:对于澳大利亚,有 5 个时区,但时区标识符要多得多:
您应该检查是否有一个包装 TZinfo 的库来处理时区 API。
例如:对于 Python,请检查
pytz
库:http:// pytz.sourceforge.net/
和
http://pypi.python.org/pypi/pytz /
在Python中你可以这样做:
但是API对于Python来说似乎相当有限,例如它似乎没有像Ruby的
all_linked_zone_names
那样的调用——它可以找到给定时区的所有同义词名称。One problem is that there are multiple "pretty names" , like "Australia/Sydney" , which point to the same time zone (e.g. CST).
So you will need to get all the possible names for the local time zone, and then select the name you like.
e.g.: for Australia, there are 5 time zones, but way more time zone identifiers:
you should check if there is a library which wraps TZinfo , to handle the time zone API.
e.g.: for Python, check the
pytz
library:http://pytz.sourceforge.net/
and
http://pypi.python.org/pypi/pytz/
in Python you can do:
but the API for Python seems to be pretty limited, e.g. it doesn't seem to have a call like Ruby's
all_linked_zone_names
-- which can find all the synonym names for a given time zone.如果评估
/etc/localtime
对您来说没问题,那么在将其翻译为 python 后,以下技巧可能会起作用:可以仅使用官方区域名称“欧洲”、“美洲”来过滤重复项。如果仍有重复,您可以采用最短的名称:-)
If evaluating
/etc/localtime
is OK for you, the following trick might work - after translating it to python:The duplicates could be filtered using only the official region names "Europe", "America" ... If there are still duplicates, you could take the shortest name :-)
安装 pytz
此代码将根据您的时区名称对您的奥尔森时区进行最佳猜测(根据 Python 的
time
模块)和您的国家/地区代码(根据Python 的hostip.info 项目,它引用您的 IP 地址并相应地对您进行地理定位)。locale
模块例如,简单地匹配 Timzone 名称可能会导致 EST (GMT-5) 的
America/Moncton
、America/Montreal
或America/New_York
)。但是,如果您所在的国家/地区是美国,则会将答案限制为America/New_York
。但是,如果您所在的国家/地区是加拿大,则脚本将默认为最上面的加拿大结果 (
America/Moncton
)。如果有进一步完善的方法,请随时在评论中留下建议。Install pytz
This code will take a best-guess crack at your Olson Timezone based both on your Timezone Name (as according to Python's
time
module), and your Country Code (as according toPython'sthe hostip.info project, which references your IP address and geolocates you accordingly).locale
moduleFor example, simply matching the Timzone Names could result in
America/Moncton
,America/Montreal
, orAmerica/New_York
for EST (GMT-5). If your country is the US, however, it will limit the answer toAmerica/New_York
.However, if your country is Canada, the script will simply default to the topmost Canadian result (
America/Moncton
). If there is a way to further refine this, please feel free to leave suggestions in comments.Python 的 tzlocal 模块正是针对这个问题。它在 Linux 和 Windows 下产生一致的结果,使用 CLDR 映射正确地将 Windows 时区 ID 转换为 Olson。
The tzlocal module for Python is aimed at exactly this problem. It produces consistent results under both Linux and Windows, properly converting from Windows time zone ids to Olson using the CLDR mappings.
这将根据 TZ 变量或本地时间文件(如果未设置)中的内容获取时区名称:
This will get you the time zone name, according to what's in the TZ variable, or localtime file if unset:
这是另一种可能性,使用 PyICU 代替;这对我的目的有用:
这里它解释本地时区的 niave 日期时间(由数据库查询返回)。
Here's another posibility, using PyICU instead; which is working for my purposes:
Here it is interpreting niave datetimes (as would be returned by a database query) in the local timezone.
我更喜欢遵循稍微比探究 _xxx 值更好的值
I prefer following a slightly better than poking around _xxx values
在大多数情况下,我更改了 tcurvelo 的脚本以找到正确的时区形式(大陆/..../城市),但如果失败则返回所有时区
I changed tcurvelo's script to find the right form of time zone (Continent/..../City), in most of cases, but return all of them if fails
此 JavaScript 项目尝试在浏览器客户端解决相同的问题。它的工作原理是与区域设置一起玩“二十个问题”,询问过去某些时间的 UTC 偏移量(以测试夏令时边界等),并使用这些结果来推断本地时区必须是什么。不幸的是,我不知道有任何等效的 Python 包,所以如果有人想使用这个解决方案,则必须将其移植到 Python。
虽然这个公式需要在每次(最坏的情况下)TZ 数据库更新时进行更新,但该算法与 Anurag Uniyal 提出的解决方案的组合(仅保留两种方法返回的可能性)在我看来是计算有效值的最可靠方法。当地时区。只要任意两个时区中至少一个本地时间的 UTC 偏移量存在一定差异,这样的系统就可以在它们之间进行正确的选择。
This JavaScript project attempts to solve the same issue in the browser client-side. It works by playing "twenty questions" with the locale, asking for the UTC offset of certain past times (to test for summer time boundaries, etc.) and using those results to deduce what the local time zone must be. I am not aware of any equivalent Python package unfortunately, so if someone wanted to use this solution it would have to be ported to Python.
While this formula will require updating every time (at worst) the TZ database is updated, a combination of this algorithm and the solution proposed by Anurag Uniyal (keeping only possibilities returned by both methods) sounds to me like the surest way to compute the effective local timezone. As long as there is some difference between the UTC offset of at least one local time in any two time zones, such a system can correctly choose between them.