<h4 dir="auto">A small, complete example of the issue</h4>
<div class="highlight highlight-source-python notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="import pandas as pd

df = pd.read_csv('greedy.txt', parse_dates=['EuroDate'])

print(df)"><pre class="notranslate"><span class="pl-k">import</span> <span class="pl-s1">pandas</span> <span class="pl-k">as</span> <span class="pl-s1">pd</span>

<span class="pl-s1">df</span> <span class="pl-c1">=</span> <span class="pl-s1">pd</span>.<span class="pl-en">read_csv</span>(<span class="pl-s">'greedy.txt'</span>, <span class="pl-s1">parse_dates</span><span class="pl-c1">=</span>[<span class="pl-s">'EuroDate'</span>])

<span class="pl-en">print</span>(<span class="pl-s1">df</span>)</pre></div>
<p dir="auto">with "greedy.txt" as</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="EuroDate
10/9/2016
30/9/2016"><pre class="notranslate"><code class="notranslate">EuroDate
10/9/2016
30/9/2016
</code></pre></div>
<h4 dir="auto">Expected Output</h4>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="    EuroDate
0 2016-09-10
1 2016-09-30"><pre class="notranslate"><code class="notranslate">    EuroDate
0 2016-09-10
1 2016-09-30
</code></pre></div>
<h4 dir="auto">Actual Output</h4>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="        EuroDate
    0 2016-10-09
    1 2016-09-30"><pre class="notranslate"><code class="notranslate">        EuroDate
    0 2016-10-09
    1 2016-09-30
</code></pre></div>
<p dir="auto"><a href="https://github.com/pydata/pandas/files/493576/greedy.txt">greedy.txt</a></p>
<p dir="auto">So <code class="notranslate">read_csv()</code> has interpreted the first line as a US-format date, then realised that the second line cannot be a US-formatted date, so switched to European format. But it has <em>not</em> gone back and reevaluated the first line in light of its new information. So the resulting data is inconsistent, and pandas knows this.</p>
<p dir="auto">Obviously, I appreciate that</p>
<ul dir="auto">
<li>CSV files are a disaster</li>
<li>This code is <em>asking</em> Pandas to infer the dates</li>
<li>Going back and re-evaluating previous data in light of new information is slow and annoying.</li>
<li>It won't always be possible to do anything except interpret a field as a string if there is inconsistent data.</li>
<li>Some datasets will include dates in multiple formats (e.g. if humans have entered them free-form) and in those cases is might just be useful for Pandas to take its best guess on a row-by-row basis.</li>
</ul>
<p dir="auto">However, I contend that in this case the behaviour is <em>incorrect</em> (because there is a consistent interpretation of the column as a date, which is in fact clear by the second record). Even if some people don't regard this as a bug, I contend that it is at the very least dangerous and likely to cause serious (and sometimes baffling) errors. In my view, it would be much better to go back and reinterpret the data according to the information now available or to fail. If even this is considered too much, at the very least Pandas should issue a prominent warning that it has interpreted different rows in the column using different date formats.</p>
<h4 dir="auto">Output of <code class="notranslate">pd.show_versions()</code></h4>
<details>
## INSTALLED VERSIONS
<p dir="auto">commit: None<br>
python: 3.5.1.final.0<br>
python-bits: 64<br>
OS: Darwin<br>
OS-release: 15.6.0<br>
machine: x86_64<br>
processor: i386<br>
byteorder: little<br>
LC_ALL: None<br>
LANG: en_GB.UTF-8</p>
<p dir="auto">pandas: 0.18.1<br>
nose: None<br>
pip: 8.1.2<br>
setuptools: 19.4<br>
Cython: 0.24<br>
numpy: 1.11.1<br>
scipy: None<br>
statsmodels: None<br>
xarray: None<br>
IPython: None<br>
sphinx: None<br>
patsy: None<br>
dateutil: 2.5.3<br>
pytz: 2016.4<br>
blosc: None<br>
bottleneck: None<br>
tables: None<br>
numexpr: None<br>
matplotlib: 1.5.1<br>
openpyxl: None<br>
xlrd: None<br>
xlwt: None<br>
xlsxwriter: None<br>
lxml: None<br>
bs4: None<br>
html5lib: None<br>
httplib2: None<br>
apiclient: None<br>
sqlalchemy: None<br>
pymysql: None<br>
psycopg2: None<br>
jinja2: 2.8<br>
boto: None<br>
pandas_datareader: None</p>
</details>
<p dir="auto">The build dependencies could be enormously simplified if we could remove the reliance of _libs/src/util.pxd on _libs/src/numpy_helper.h.  I've ported most of the functions directly to util.pxd, would like input on a few remaining ones.</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="PANDAS_INLINE PyObject* get_value_1d(PyArrayObject* ap, Py_ssize_t i) {
    char* item = (char*)PyArray_DATA(ap) + i * PyArray_STRIDE(ap, 0);
    return PyArray_Scalar(item, PyArray_DESCR(ap), (PyObject*)ap);
}"><pre class="notranslate"><code class="notranslate">PANDAS_INLINE PyObject* get_value_1d(PyArrayObject* ap, Py_ssize_t i) {
    char* item = (char*)PyArray_DATA(ap) + i * PyArray_STRIDE(ap, 0);
    return PyArray_Scalar(item, PyArray_DESCR(ap), (PyObject*)ap);
}
</code></pre></div>
<p dir="auto">It looks like this just returns <code class="notranslate">ap[i]</code>.  Presumably more efficient in some way.  I'm guessing this was written before typed memoryviews were available in cython; there may be a less verbose plain-cython alternative available.</p>
<p dir="auto">Alternatively, everything there except for <code class="notranslate">PyArray_DESCR</code> can cimported with a little effort.  If anyone knows of a way to get at this last piece, then both <code class="notranslate">get_value_1d</code> and <code class="notranslate">assign_value_1d</code> can be moved directly into <code class="notranslate">util</code>.</p>