Question

我正在使用dateutil库来解析一些日期字符串，并获得奇怪的结果。我假设以下日期字符串都是相同的，并且括号中的时区缩写实际上是可选的，但删除它会得到一个完全不同的值：

import datetime   
import dateutil.parser

parsed_d1 = dateutil.parser.parse('Sun May 13 2012 00:00:00 GMT-0400 (EDT)')   
parsed_d2 = dateutil.parser.parse('Sun May 13 2012 00:00:00 GMT-0400')   
parsed_d3 = dateutil.parser.parse('Sun May 13 2012 00:00:00-0400')   

print str(parsed_d1)   
print str(parsed_d2)   
print str(parsed_d3)

输出：

2012-05-13 00:00:00-04:00   
2012-05-13 00:00:00+04:00   
2012-05-13 00:00:00-04:00

有谁能解释这里发生了什么？

Answer 1

EDT适用于英国西部的美国。太阳从东边升起。所以太阳在美国之前在英国的头顶上空。所以你需要在EDT上加4小时才能获得GMT。这就是为什么我需要在下午晚些时候打电话给我的父母（在英国），或者他们在床上。换句话说：“EDT +4是GMT”。

现在这个来源是http://bazaar.launchpad.net/~dateutil/dateutil/trunk/view/head:/dateutil/parser.py，而且似乎与解析GMT-0400相关的评论说

# Check for something like GMT+3, or BRST+3. Notice
# that it doesn't mean "I am 3 hours after GMT", but
# "my time +3 is GMT". If found, we reverse the
# logic so that timezone parsing code will get it
# right.

这意味着GMT-0400相当于“我的时间-4是GMT”。不与上述相同。

另外，如果您查看代码，则在之后处理的尾随(EDT)，因此优先。并且我认为第三种情况，最后的简单-0400按照您的预期处理。

换句话说（在我看来，从扫描代码开始）GMT-0400表单作为代码文档工作，但不是你想象的那样。 该行与其他两行不等。

我不知道为什么代码会这样运作;我只是报道我读到的内容。

最后，请注意该代码中的一般方法是按块执行整个日期字符串块，将不同的逻辑应用于不同的位置。没有那么多检查以确保不同位置的逻辑是一致的（因此第一行中明显的矛盾没有引起错误）。就个人而言，我更喜欢使用python自己的日期解析例程的库，但尝试不同的格式字符串 - 我怀疑它会更可靠（但可能不太灵活）。

更新我已经忘记了这篇文章，但在写完这篇回复一段时间后，我写了simple-date来处理时区的解析。它采用的方式更像我说的首选 - 它不是试图变得聪明，而是在pytz数据库中搜索匹配。

奇怪的日期解析结果在Python中

1 个答案: