Not sure what may have changed here over the past 3 years, but some current findings:

For _UnixSelectorEventLoop, "/usr/lib/python3.5/selectors.py", line 445, in select, fd_event_list = self._epoll.poll(timeout, max_ev), Python 3.5.3 (or 3.6.1), Linux 4.10.0-19 x86_64 (or Cygwin 2.8.0):

2,147,483 is acceptable, 2,147,484 is not.  (Either side of 2**31/1000.)  With the seconds/milliseconds conversions, I suppose the previous testing here just didn't get this specific - but this is only 24.86 days, just ever so slightly above half of the "48 days" figure mentioned below.  So no, not even the "maximum timeout of 30 days" previously proposed would be sufficient - though the currently documented "one day" maximum is.

So if intending to use this as a serious scheduler, what to do?  I considered checking for values more than 86,400 (1 day) before scheduling - and if in excess, instead scheduling a proxy that would repeatedly reschedule the next interval as needed in < 1 day increments.  However, this would require some special handling of the asyncio.Handle's that are returned to cancel the callback - as a new handle would be required for each renewal.

It would seem that a better and simpler approach could simply be to ensure that a recurring "dummy" task (or heartbeat) is scheduled to run every 1 day or less.  As long as a another task is scheduled in the queue ahead of any tasks with "excessively long" delays, the longer delay will never be passed to poll() until it is reduced to within the smaller threshold.  I can do this within my own code - but this could maybe also be further considered to happen automagically within asyncio.  Am I missing any further considerations or gotchas here?

(See also: http://stackoverflow.com/questions/27129037/why-is-there-a-limit-on-delayed-calls-like-asyncio-call-later-to-not-exceed-one)