<div dir="ltr">Well, I was only yesterday complaining at github about the silent default of read_csv converting 'NA' to NaN.   ;-)  So I have to agree with Lorenzo that this is a good change.  It also seems more consistent with pandas overall behavior.<br><br>FWIW, Stata's default with these sorts of operations is always to tell you how many values were changed, which is often very helpful.  E.g. if Stata tells you zero values were changed, this is a big clue you screwed up.  Often this is more verbose than desired, but it's also easy to change that.<br><br>So, I'm definitely fine with just making it an error, but a possible middle ground would be a short report like:  "20 values changed, 5 values not changed".<br><br><br>On Thursday, July 23, 2015 at 9:51:11 AM UTC-4, Lorenzo De Leo wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir="ltr">Personally I'm very much in favor of this change. I don't like silent defaults ;)<div><br></div><div>L</div><div><br><br>On Wednesday, July 22, 2015 at 4:59:31 PM UTC+2, Joris Van den Bossche wrote:<blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi all,<br><br>On github there is a proposal to change the default behaviour of <span style="font-family:monospace,monospace">to_datetime</span> in case of a parsing error from 'ignore' (leaving the values untouched) to 'raise' (raise an error).<br><br></div>As a small example, the current behaviour:<br><br><span style="font-family:monospace,monospace">In [5]: pd.to_datetime('2014-30-30', errors='ignore')   # the default now<br>Out[5]: '2014-30-30'<br><br>In [6]: pd.to_datetime('2014-30-30', errors='raise')<br>...<br>ValueError: month must be in 1..12</span><br><br><div><br></div><div>So the proposal would be to change the default to the second case, raising an error.<br><br></div><div>Note that this behaviour is already the default when providing your own <span style="font-family:monospace,monospace">format </span>(and so in fact ignoring the value of the <span style="font-family:monospace,monospace">errors </span>keyword):<br><span style="font-family:monospace,monospace"><br>In [7]: pd.to_datetime('2014-30-30', format='%Y-%m-%d')<br>...<br>ValueError: time data '2014-30-30' does not match format '%Y-%m-%d'</span><br><br></div><div><b>Are there any objections to this change? <br></b></div><div><b>Are there people relying on the fact that, by default, to_datetime returns the exact original value if parsing does not succeed?</b><br></div><div><br></div><div>Best regards,<br></div><div>Joris<br></div></div>
</blockquote></div></div></blockquote></div>