Converting datetimes with non-trivial timezones to datetime64 is broken on python 2.6 #7336
Comments
|
Even if we go with the latter, the test should be marked as a known failure at least for Python 2.6. |
|
Also, @shoyer, figured I would raise this to your attention as the discussion has moved here and I figure you would want a say on this. |
|
This code path has actually been around for years (from some of the original datetime64 work), but it was never tested. What #6453 added was actually deprecation test that happens to exercise this otherwise untested code path. Given that this code path is now deprecated and in fact never worked on Python 2.6, I think we can safely call it a "bug", skip that test on Python 2.6 and move on. I guess it would be a good idea to fix it in theory, but it seems pretty pointless to me (nobody is currently relying on this) and counter-productive to encourage users to rely on deprecated behavior. |
|
I added this ( #7337 ) to mark that test as a known failure. May need the wording tweaked. |
|
Also, sorry for the confusion @shoyer. I only noticed the test was added then. I did not know the full story behind it. |
|
Also, maybe we can install |
|
Closed by #7337. |
As discussed in #7324, #6453 added a code path that references the
timedelta.total_seconds()method, which is new in 2.7. We didn't notice this because the code path is only hit when converting Pythondatetimeobjects todatetime64, and only fordatetimeobjects that have a.tzinfoattribute which is notNone, and it turns out that we don't install pytz on Travis/Appveyor and so never actually ran this test on 2.6.This is totally uninteresting for master, because master has already dropped 2.6 support (except that we should install pytz on Travis/Appveyor, which is #7335).
Options:
td.days * 86400 + td.seconds, though this is a bit annoying to do from C)I guess I'm leaning towards the latter.
The text was updated successfully, but these errors were encountered: