test_parse_date_string fails comparing offset-naive and offset-aware types about datefinder

[akoumjian]

@thebigspoon care to elaborate?

[ranchodeluxe]

@lindauer: Yummy!
Could you tell me what operating system you are on?
Could you also run the following commands in a Python shell with an environment that has python-dateutil installed? Let me know what gets returned please:

In [23]: import dateutil
In [24]: dateutil.tz.gettz('IRST')

breakdown

Yes, the problem is the test and probably the assumption that the operating system the test is running on doesn't have zoneinfo for the timezone abbreviation -- IRST. Good catch!

dateutil.tz.gettz is basically a big if/else booby trap hunting for the right timezone files ( here ). On Ubuntu 14.04 it is looking to resolve IRST at this location:

In [22]: ls -lah /usr/share/zoneinfo/I*
-rw-r--r-- 1 root root 1.2K Jun 13  2014 /usr/share/zoneinfo/Iceland
-rw-r--r-- 1 root root 1.7K Jun 13  2014 /usr/share/zoneinfo/Iran
-rw-r--r-- 1 root root 2.2K Jun 13  2014 /usr/share/zoneinfo/Israel

It doesn't find it and therefore tries to replace the tzinfo with None which mean it returns a naive datetime ( here ) as the test was designed.

My guess is that the dateutil.tz.gettz lookup resolves for you and returns legitimate tzinfo.

The test should probably use a really really wrong timezone abbreviation such as NOT_A_TIMEZONE ;-)

[lindauer]

It actually returns None for me, too. Upon closer examination, I think it's the CST test failing, not the IRST test. I'm on OSX 10.10.5.

[ranchodeluxe]

@lindauer:
so this does return something for you?

In [23]: import dateutil
In [24]: dateutil.tz.gettz('CST')

[lindauer]

It does!

>>> import dateutil.tz
>>> dateutil.tz.gettz('CST')
tzlocal()

[ranchodeluxe]

@lindauer: thanks for sticking with this. I was able to reproduce the recurring issue you mention in PR #12 on OSX. For some reason the mock was not taking in the environment of OSX and anaconda. It's was working fine on Ubuntu and CentOS.

So I've adjusted the mock in PR #13. If you could merge that PR locally and test it out I'd really appreciate it.

[ranchodeluxe]

works, see notes on PR #13. closing