-
-
Notifications
You must be signed in to change notification settings - Fork 18.5k
TST: test failures on 3.4/windows for timezones #7420
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
cc @dbew good news is all other versions are ok! |
this is python 34-32 and 34-64 |
Thanks. We're getting there. Just looking at the test code, I'm surprised by the error for I can't compile pandas on python 3.4 on windows right now - I'm getting linker errors. I've tried fiddling around with the settings but no luck yet. I've been using anaconda + mingw so far but googling suggests that the platform sdk would be better. I can't get that set up at work though. I'll try and find some time when I get home this evening. Btw, I've been doing the coding for this dateutil integration at work and the company I work for would like to have their contribution recognized in the release notes. I'm aware that this might not be the place to ask but I couldn't find a better place on github. Do you know if that's possible? |
Heres a copy of the scripts I use on windows. I found installing the windows SDK was easier/straightforward that mingw. https://github.com/pydata/pandas/tree/master/scripts/windows_builder |
@dbew I don' t have a problem with company mention (and you too!). Something like 'contributed by David Bew and blah blah....`. |
here's some debugging info
|
How come there are four failures this time and I made some progress with py3.4 - I can install cython successfully - but didn't quite get pandas building. I'll try again this evening. |
those other ones might be suprious..... |
@dbew ? |
Now have pandas compiled on python3.4 on windows. This is a bit weird. If I run None of the tests are failing if I run them one at a time with nose and working through the original two failures in ipython, I don't see any problems with the results. As far as I can tell, none of these tests should be failing. I'll keep digging but if you have any ideas of what could be wrong I'd be pleased to hear them! |
hmm...maybe some sort of global/module state is being modified in the tests? |
I guess it must be - but why is that only a problem on python 3.4 on windows? If there was a modification to the pandas global state which is breaking the tests, I'd expect that to be a problem across windows versions (and on linux, for that matter). |
@dbew agreed this is odd. But then again its possible dateutil is doing something internally that is 'broken' in 3.4 in the speicifc cases we are testing. not sure. 3.4. DOES break some other very subtle things (which might be techinically incorrectly done in prior versions). |
Ok, like I said, I'll keep digging and see if I can replicate this in a smaller example. |
I now have a nice small example that fails in ipython! from pandas import date_range, DatetimeIndex
dr = date_range('2012-06-02', periods=10, tz='dateutil/US/Eastern')
dr2 = DatetimeIndex(list(dr), name='foo')
dr.equals(dr2)
OUT: True
dr = date_range('2012-06-02', periods=10, tz='US/Eastern')
dr2 = DatetimeIndex(list(dr), name='foo')
dr.equals(dr2)
OUT: False |
hmm, the 2nd just fails for a trivial reason, e.g .the frequency is not inferred (but if you look at |
I've found the problem. I'll submit a PR shortly. The issue was cache collisions between pytz and dateutil timezones in the transition/utc_offset caches in pandas.tslib. I've modified the cache key so that it distinguishes between the two and added a test to ensure that this is the case. I think the intermittent nature was due to the order of use - e.g. using pytz before dateutil was ok because of the nature of the differences between them. |
The text was updated successfully, but these errors were encountered: