Parser UTC offset logic is inverted

[atttx123]

my python-dateutil version: 2.4.1

i am in the time zone: CST(UTC+8)

when i use dateutil, it return different with other tools

pyhton-dateutil:

In [21]: parse("2015-03-31 00:01 UTC").astimezone(cst)
Out[21]: datetime.datetime(2015, 3, 31, 8, 1, tzinfo=tzlocal())

In [22]: parse("2015-03-31 00:01 UTC+1").astimezone(cst)
Out[22]: datetime.datetime(2015, 3, 31, 9, 1, tzinfo=tzlocal())

In [23]: parse("2015-03-31 00:01 UTC-1").astimezone(cst)
Out[23]: datetime.datetime(2015, 3, 31, 7, 1, tzinfo=tzlocal())

linux date command:

yu at debian in ~ 
(! 4076)-> date -d "2015-03-31 00:01 UTC"
Tue Mar 31 08:01:00 CST 2015
yu at debian in ~ 
(! 4076)-> date -d "2015-03-31 00:01 UTC+1"
Tue Mar 31 07:01:00 CST 2015
yu at debian in ~ 
(! 4077)-> date -d "2015-03-31 00:01 UTC-1"
Tue Mar 31 09:01:00 CST 2015

[atttx123]

i think it is the parse return a wrong tzoffset

In [21]: parse("2015-03-31 00:01 UTC-1")
Out[21]: datetime.datetime(2015, 3, 31, 0, 1, tzinfo=tzoffset(None, 3600))

In [22]: parse("2015-03-31 00:01 UTC+1")
Out[22]: datetime.datetime(2015, 3, 31, 0, 1, tzinfo=tzoffset(None, -3600))

[pganssle]

@atttx123 Given that tzlocal() is CST, are you sure that that is the wrong answer? I looked into something similar for issue #64, and came to the conclusion that tzlocal() and a local time zone are equivalent.

Additionally, can you clarify where cst is coming from? It seems likely that you are generating it by calling:

>>> from dateutil.tz import gettz
>>> cst = gettz('CST')
>>> print(cst)
tzlocal()

If you're in the chinese standard time zone (on linux), gettz('CST') will return tzlocal(), because 'CST' is one of the local time zones. If you want to specifically retrieve a time zone from the tzfile, not your local time zone, you can specify the locale string:

>>> from dateutil.tz import gettz
>>> cst = gettz('Asia/Shanghai')
>>> print(cst)
tzfile('/usr/share/zoneinfo/Asia/Shanghai')

Honestly, though, it seems to me like you're getting the right values out, so I'm not clear that there's a problem with using tzlocal() in this case.

[pganssle]

@atttx123 I'm going to assume that you are satisfied and close this as not a bug. If this is mistaken let me know and I can reopen.

[atttx123]

@pganssle the point is not the timezone, its the parse function itself

when time is 00:00 UTC+1, my local time should be 07:00 UTC+8
but for dateutil, it return 09:00:

In [6]: parse("2015-03-31 00:00 UTC+1").astimezone(cst)
Out[6]: datetime.datetime(2015, 3, 31, 9, 0, tzinfo=tzfile('/usr/share/zoneinfo/Asia/Shanghai'))

[atttx123]

on linux ,you can use this cmd to check time:

date -d "2015-03-31 00:01 UTC+1"

i am sure dateutil return a wrong answer

[pganssle]

Ah, sorry, I missed that. My bad. I'll look into it.

[pganssle]

@atttx123 Hm... This will require careful thought on how to address this, unfortunately. It seems that this was a deliberate choice, as seen in this comment. Interestingly, another comment in the tz module specifically mentions that tzstr has the opposite behavior.

If it's a problem, I'm not clear on why it hasn't been noticed before - this has been the behavior since at least dateutil 2.1.

[atttx123]

i think the parse should behave same with other tools like date command, otherwise it will make people confuse

[pganssle]

@atttx123 I agree in general, but it's important to determine if this is a bug that no one has noticed, a bug in date or if this is the well-known behavior of the library. If we want to switch the logic to the more common version, we may want an intermediate version that raises a deprecation warning.