title: Erratic behaviour when mixing pandas, datetime and numpy timedelta (bug?)
body: <p>I have noticed by chance that some operations (a > b) on datetime that should give the same (well-defined) results actually give different results (some correct, some wrong, some just throwing an error) depending on whether I do them on a pandas dataframe or in numpy. I try to give a small example below. For brevity, I use dateutile.parser.parse function, but I think that the issue comes up in the interplay between datetime, pandas and numpy packages, in particular when using pandas' DatetimeIndex.</p>
  
  <p>First I try to create a df out of np.timedelta64, and that I can't compare to a single np.timedelta64; it's a clean error, which I think is ok:</p>
  
  <pre><code>import numpy as np
  import pandas as pd
  from dateutil.parser import parse
  a1 = np.array([np.datetime64(parse('20200101')),np.datetime64(parse('20150101'))]).reshape((1,-1))
  a2 = np.array([np.datetime64(parse('20100101')),np.datetime64(parse('20180101'))]).reshape((-1,1))
  df1 = pd.DataFrame(a1-a2)
  df1 &gt; np.timedelta64(1000,'D')
  </code></pre>
  
  <p>With the above df1 is:</p>
  
  <pre><code>    0                       1
  0   3652 days 00:00:00  1826 days 00:00:00
  1   730 days 00:00:00   -1096 days +00:00:00
  </code></pre>
  
  <p>and the second command throws an error "TypeError: ufunc 'isnan' not supported for the input types, and the inputs could not be safely coerced to any supported types according to the casting rule ''safe''". So far, so good.</p>
  
  <p>However, if I write:</p>
  
  <pre><code>a3 = pd.DatetimeIndex(a1.flatten()).values.reshape((1,-1))
  df2 = pd.DataFrame(a3 - a2)
  </code></pre>
  
  <p>then the result looks similar: df2 = </p>
  
  <pre><code>    0           1
  0   3652 days   1826 days
  1   730 days    -1096 days
  </code></pre>
  
  <p>But in this case, <code>df2 &gt; np.timedelta64(1000,'D')</code> not only does not throw an error, but it gives a wrong answer:</p>
  
  <pre><code>    0       1
  0   True    True
  1   True    False
  </code></pre>
  
  <p>On the other hand, if instead of doing <code>pd.DataFrame(a3-a2) &gt; np.timedelta64(1000,'D')</code>, we do <code>pd.DataFrame(a3-a2 &gt; np.timedelta64(1000,'D'))</code>, we get the good answer:</p>
  
  <pre><code>    0       1
  0   True    True
  1   False   False
  </code></pre>
  
  <p>Given the situation, I imagine there must be a bug somewhere, although I am not quite sure where. Maybe I am just misunderstanding some notations, but the behavior is a bit puzzling anyway. Some issue may come from the fact that, with the above definitions, some dtypes (e.g. df1) are in microseconds, some other (e.g. df2) are in nanoseconds; however, I expect these should be treated correctly, since the output is correctly transformed to days...</p>
  
  <p>For reference, I am using Python 3.5, numpy version 1.12.1, pandas version 0.18.0, and python-dateutil version 2.5.1.</p>
  
  <p>EDIT: After further testing, and taking into account Paul's answer below:</p>
  
  <ul>
  <li><p>The error has apparently been solved with Pandas version 0.19.2. Paul's code snippet below, as well as the code above concerning df2, have been tested by Paul to correctly work under Linux, Python3.5, Pandas 0.19.2, and I have also checked them under both Linux and windows, both Python2.7 and Python3.5, Pandas 0.20.2.</p></li>
  <li><p>In 0.18.2, Paul's code snippet below gives the same (wrong) answer as df2 above.</p></li>
  <li><p>However, in my tests, also in 0.20.2, the first code above (df1 on this question) gives a wrong answer, giving all False. This is probably due to the fact that pandas stores the dates as microseconds (because Paul's explicit cast solves the issue), while numpy as nanoseconds, so there is a silent factor of 1000. Still, I would think that this should be taken care of automatically...</p></li>
  </ul>