I've been giving a lot of thought as to the Python 2 deprecation schedule for dateutil, and I think I have come up with a tentative plan. Before I go ahead and put it on Python 3 statement, I'd appreciate any comments if people think this is unrealistic or could be done better.

Here is my current plan and timeline:

1. August-September 2018: 3.0 release - Supporting Python 2.7, 3.4+
   We have a lot of deprecated behavior in the 2.x branch that I'd like to remove, and a few small breaks to backwards compatibility that I'd like to make that aren't really something that can be deprecated (e.g. the behavior of dayfirst and yearfirst that has so many people pinned on 2.4.x). Ideally, we'd also have the new parser up and running before then.
2. January 2019: 4.0 release - Supporting only Python 3.4+. Version 3.0 becomes LTS, bugfixes only.
   This release should make basically no breaking changes other than dropping support for Python 2, so that people can write Python 2/3 compatible code pinned to python-dateutil < 5.0.0, rather than doing more complicated backports.
3. July 2019 - Final bugfix release for version 3.0. Zoneinfo support continues indefinitely.

After the 4.0 release, I think we'll want to make at least a 6 month deprecation period before any more backwards-compatibility breaking changes are made.

Somewhere in here I'm also planning to put in a compiled backend, but I think that will be opt-in for at least the 2.x branch.

@Carreau gave a talk about how best to drop support for Python 2 that I basically agree with at PyBay 2017. You can find the video here.

CC @jbrockmendel @jdufresne @jreback