CLN: Removed coerce param in pd.to_timedelta and pd.to_datetime
State: closed

Deprecated back in `v0.17.0` <a href="https://github.com/pydata/pandas/commit/987b7e7e586b8df1d127406c69e0a9094a1a5322">here</a>.  Seems appropriate to carry though now.


Labels:
name: Timedelta
description: Timedelta data type
name: Deprecate
description: Functionality to remove in pandas

Comments:
## [Current coverage](https://codecov.io/gh/pydata/pandas/pull/13602?src=pr) is 85.30% (diff: 100%)

> Merging [#13602](https://codecov.io/gh/pydata/pandas/pull/13602?src=pr) into [master](https://codecov.io/gh/pydata/pandas/branch/master?src=pr) will increase coverage by **0.04%**

``` diff
@@             master     #13602   diff @@
==========================================
  Files           140        139     -1   
  Lines         50634      50139   -495   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
- Hits          43173      42771   -402   
+ Misses         7461       7368    -93   
  Partials          0          0          
```

> Powered by [Codecov](https://codecov.io?src=pr). Last update [d98e982...c8c5f49](https://codecov.io/gh/pydata/pandas/compare/d98e982ecb0f6b7f3478a63caac34e0be238895c...c8c5f49d059bb60330cab4a097a6eb7a350949db?src=pr)

@jreback : Travis is passing, so ready to merge if there are no other concerns.

actually, I don't think this can be done w/o doing for `to_datetime` as well. Either both or none.

and we generally are waiting much longer, see the list @jorisvandenbossche put up at the very bottom:
https://github.com/pydata/pandas/issues/6581 

any of those are fair game. Yes we could/should do some of the 0.17.0 ones, but let's get some of the others first.

@jreback : so if I also remove the `to_datetime` param, will this be merged in for `0.19.0` or not?  A duration of two major releases seems like a good amount of time for people to adjust their code I thought.

@gfyoung yes it is _normally_ ok, but we SO many deprecations (esp from 0.17.0.), that I think let's clean everything up thats < 0.17.0 first. So I would say defer this to 0.20.0..

@jreback : Hmm...I'm not sure I totally follow that logic, especially since I do see a deprecation removal from `0.17.0` being listed in that issue that you linked to (the legacy offsets one).

yeah. I don't have a problem with anything from 0.17.0. BUT this is a 'biggie' (well to_datetime is really). So no objection if you include both (for consistency). But if you have a limited pool of PR energy, would prefer other ones to be addressed .....

@jreback : this one isn't that difficult to remove AFAICT - I'll also take a look at some of the other deprecation removals and put up PR's for those if I can.

right, add on `to_datetime` removal then would be ok, but @jorisvandenbossche might feel different.

@jreback : fair enough - in the meantime, I think we do have one deprecation removal that I think all of us can agree upon (#13419) :smile: 

@jreback : removed the `coerce` parameter in `to_datetime`, and Travis is still passing. @jorisvandenbossche thoughts?

Personally I would table this for 0.20 .. 
The other deprecated things we are removing are all even from 0.15 and (the maybe's) from 0.16 (except for the offset/freq PR), and the 0.17 release is less than a year old.

Maybe we need some more 'formal' rules on how long deprecations are kept at the minimum? Eg minimal two feature releases and minimal a year.

@jorisvandenbossche: When has two feature releases ever taken more than a year?  Two feature releases sure, but a year seems a little long too me, and not just because I would like to merge this ;)

I think let's defer this one to 0.20. I don't see any downside to delaying this.

> but a year seems a little long too me, and not just because I would like to merge this ;)

We may not like it, but it is a fact that not all users upgrade each version but often skip a few at once ... 
I understand you rather see it merged, but rebasing it in a few months will also not be that much work!

@jorisvandenbossche : this deprecation removal process is somewhat new to me, and I was not aware of user tendencies to skip version upgrades (I generally follow them quite closely for my projects).  However, I perfectly understand!  I was being somewhat facetious when I mentioned that I wanted to merge this now from the `;)` I added at the end.

@gfyoung as a further data point. We have tended to deprecate a lot, and only are now catching up with removals. I think 0.19/0.20 will be a good fix point for some of this.

@gfyoung can you force push again? (possibly due to the repo transfer the PRs open before the transfer cannot be merged from the github interface)

@jorisvandenbossche if you merge this, we for sure need to branch 0.19.1 (which is ok)

also should remove `coerce` from `pd.to_datetime` for consistency.

@jreback : Ah, good point.  I didn't realize it had been deprecated back in `0.17.0`.  Will do then.

@jreback : Actually, never mind!  I did remove it in this PR!  Need to change the title.

ok lgtm. our first non-0.19.1 PR!

Merged! Thanks @gfyoung 

@jorisvandenbossche so need to branch 0.19.1 (as this should not be included)!