3

我正在使用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

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

4

1 回答 1

3

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 是格林威治标准时间”。这与上面的不一样。

另外，如果您查看代码，则会在此之后(EDT)处理尾随，因此具有优先权。我认为第三种情况，最后，简单的处理方式如你所料。-0400

换句话说（在我看来，从扫描代码来看）该GMT-0400表单正在作为代码文档工作，但不像您期望的那样。那条线不等同于其他两条。

我不知道为什么代码会这样工作；我只是报告我读到的。

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

更新我已经忘记了这篇文章，但是在写完这个回复后不久，我写了简单的日期来处理时区的解析。它采用了一种更像我所说的我更喜欢的方法 - 它不是试图变得聪明，而是在 pytz 数据库中搜索匹配项。

于 2012-05-14T02:13:19.267 回答