时区偏移量符号被dateutil颠倒了吗？ [英] Timezone offset sign reversed by dateutil?

问题描述

有人知道为什么python的dateutil在解析datetime字段时会反转GMT偏移量的符号吗？

显然，此功能是，//stackoverflow.com/questions/19932429/get-tz-offset-from-sting>已知结果。但这会导致错误日期时间结果，除非应用了预处理黑客程序

  from dateutil import parser 
 
 jsDT ='Fri Jan 02 2015 03：04：05.678910 GMT-0800'
 python_datetime = parser.parse（jsDT）
打印（python_datetime）
 >>> 2015-01-02 03：04：05.678910 + 08：00 
 
 jsDT ='星期五02 2015 03：04：05.678910 GMT-0800'
如果jsDT中为'-'：
 jsDT = jsDT.replace（'-'，'+'）
 elif'+'in jsDT：
 jsDT = jsDT.replace（'+'，'-'）
 python_datetime = parser.parse（jsDT）
 print（python_datetime）
>> 2015-01-02 03：04：05.678910-08：00 
  

解决方案

似乎 dateutil 在这里使用POSIX样式的标志。它与Python不相关。其他软件也可以。来自 tz数据库：

 ＃我们在区域名称和输出缩写
＃中使用POSIX样式的符号，即使这与许多人的预期相反。 
＃POSIX在格林威治以西有积极的迹象，但许多人期望
＃在格林威治以东的积极迹象。例如，TZ ='Etc / GMT + 4'使用
＃的缩写 GMT + 4，并且比UT 
＃落后4小时（即格林威治以西），即使许多人希望这样做至
＃表示比UT提前4个小时（即格林威治以东）。 
  

几乎所有地方都使用了tz数据库。

示例：

  $ TZ = Etc / GMT-8日期+％z 
 +0800 
  

您可能期望使用不同的时区：

 >>从datetime导入datetime 
>>导入pytz 
>> pytz.timezone（'America / Los_Angeles'）。localize（datetime（2015，1，2，3，4，5，678910），is_dst = None）.strftime（'％Y-％m-％d％H：％ M：％S.％f％Z％z'）
'2015-01-02 03：04：05.678910 PST-0800'
  

注意： PST ，而不是 GMT 。

尽管 dateutil 甚至使用 PST 时区缩写也使用POSIX样式的符号：

 >>从dateutil.parser导入解析
>> str（parse（'2015-01-02 03：04：05.678910 PST-0800'））
'2015-01-02 03：04：05.678910 + 08：00'
  

datetime.strptime（）在Python 3中正确解释：

  $ TZ = America / Los_Angeles python3 
 ... 
>>从datetime导入datetime 
>> str（datetime.strptime（'2015-01-02 03：04：05.678910 PST-0800'，'％Y-％m-％d％H：％M：％S.％f％Z％z'））
'2015-01-02 03：04：05.678910-08：00'
  

注意

尽管由于POSIX样式的标志而造成混乱； dateutil 行为不太可能改变。请参见 dateutil 错误： GMT + 1被解析为 GMT-1 ，@ Lennart Regebro的回复：

这种方式解析GTM + 1实际上是其中一部分Posix规范。
因此，这是一个功能，而不是错误。

请参阅 TZ 环境变量在POSIX规范中定义， glibc使用类似定义。

不清楚为什么 dateutil 使用POSIX TZ 的语法，用于解释时间字符串中的时区信息。语法不完全相同，例如POSIX语法要求使用分号：utc偏移中的 hh [：mm [：ss]] 在输入中不存在。 / p>


Does anyone know why python's dateutil reverses the sign of the GMT offset when it parses the datetime field?

Apparently this feature is a known outcome of not only dateutil but also other parsing functions. But this results in an incorrect datetime result unless a pre-processing hack is applied:

from dateutil import parser

jsDT = 'Fri Jan 02 2015 03:04:05.678910 GMT-0800'
python_datetime = parser.parse(jsDT)
print(python_datetime)
>>> 2015-01-02 03:04:05.678910+08:00

jsDT = 'Fri Jan 02 2015 03:04:05.678910 GMT-0800'
if '-' in jsDT:
    jsDT = jsDT.replace('-','+')
elif '+' in jsDT:
    jsDT = jsDT.replace('+','-')
python_datetime = parser.parse(jsDT)
print(python_datetime)
>>> 2015-01-02 03:04:05.678910-08:00

解决方案

It seems dateutil uses POSIX-style signs here. It is not related to Python. Other software does it too. From the tz database:

# We use POSIX-style signs in the Zone names and the output abbreviations,
# even though this is the opposite of what many people expect.
# POSIX has positive signs west of Greenwich, but many people expect
# positive signs east of Greenwich.  For example, TZ='Etc/GMT+4' uses
# the abbreviation "GMT+4" and corresponds to 4 hours behind UT
# (i.e. west of Greenwich) even though many people would expect it to
# mean 4 hours ahead of UT (i.e. east of Greenwich).

The tz database is used almost everywhere.

Example:

$ TZ=Etc/GMT-8 date +%z
+0800

You probably expect a different timezone:

>>> from datetime import datetime
>>> import pytz
>>> pytz.timezone('America/Los_Angeles').localize(datetime(2015, 1, 2, 3, 4, 5, 678910), is_dst=None).strftime('%Y-%m-%d %H:%M:%S.%f %Z%z')
'2015-01-02 03:04:05.678910 PST-0800'

Note: PST, not GMT.

Though dateutil uses POSIX-style signs even for the PST timezone abbreviation:

>>> from dateutil.parser import parse
>>> str(parse('2015-01-02 03:04:05.678910 PST-0800'))
'2015-01-02 03:04:05.678910+08:00'

datetime.strptime() in Python 3 interprets it "correctly":

$ TZ=America/Los_Angeles python3                                               
...
>>> from datetime import datetime
>>> str(datetime.strptime('2015-01-02 03:04:05.678910 PST-0800', '%Y-%m-%d %H:%M:%S.%f %Z%z'))
'2015-01-02 03:04:05.678910-08:00'

Notice the sign.

Despite the confusion due to POSIX-style signs; dateutil behavior is unlikely to change. See dateutil bug: "GMT+1" is parsed as "GMT-1" and @Lennart Regebro's reply:

Parsing GTM+1 this way is actually a part of the Posix specification. This is therefore a feature, and not a bug.

See how TZ environment variable is defined in the POSIX specification, glibc uses similar definition.

It is not clear why dateutil uses POSIX TZ-like syntax to interpret the timezone info in a time string. The syntax is not exactly the same e.g., POSIX syntax requires a semicolon: hh[:mm[:ss]] in the utc offset that is not present in your input.

这篇关于时区偏移量符号被dateutil颠倒了吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！