Adding datetimes() to the core strategies

[Zac-HD]

Let's start with the problem statement: the interface for time-related strategies is not good, timedeltas are missing, and users might not know that extras exist. So here's my proposal:

Add a new datetimes core strategy, with three arguments: min, max, and a tzinfo strategy - mimicking the collections with an elements= substrategy.

datetimes(min_datetime=dt.datetime.min, 
          max_datetime=dt.datetime.max, 
          timezones=none())

This has a pleasingly orthogonal API. The bounds are of the right type to express the full resolution of the strategy (#421), and after wrestling with #556 I propose to only accept naive bounds. Conceptually it's a naive strategy that can add in tzinfo at the end, which is easier to implement and understand.

Using a SearchStrategy for the timezones argument resolves the conflicts between the old allow_naive and timezones arguments - your timezones are whatever can be drawn from the strategy, including None. It also makes it much easier to extend - to draw aware timezones, simply set e.g. timezones=sampled_from([pytz.timezone(tz) for tz in pytz.all_timezones])

Additional work, and why not to do it:

• timedeltas, as a new and entirely separate strategy, will have a separate pull request (again).
• dates and times are trivial to construct (datetimes().map(dt.datetime.date) and datetimes().map(lambda t: t.timetz()) respectively), so I don't think it's worth adding new strategies to the public API for them at this time.
• An example timezones() strategy was given above. I'm not inclined to build one in until I have some experience of how it would be used. (e.g.: do people want to limit geographically, by utcoffset, etc) sampled_from(some_timezones) is OK as a placeholder, with good docs.

[alexwlchan]

I am generally 👍 on this proposal:

• Simplifying the API is a win, especially dropping the allow_naive argument.
• We get to deprecate all usage of the existing datetimes strategy, which makes the logic for doing so a lot simpler. Are you using this strategy? Deprecated!
• Moving it into the core strategies is a win.
• I would put in the dates() and times() strategy, because it’s an easy extension for us, and makes for a more friendly API for end-users. Having map() is good, but I think of it as a slightly more advanced concept, and the more we can expose directly in the hypothesis.strategies API, the better.

[Zac-HD]

super simple draft of the initial implementation. No tests, deprecation, etc, but you get the idea. It's certainly more elegant this way!