This is a preliminary implementation of the feature suggested in #4736.

I wanted to get something down in code to further our ability to discuss API and implementation options. Even if we decide not to change any of the main points, I will go over the implementation again for style and documentation, improve the tests, update the docs, and write a changelog entry.

I implemented approximate comparison for both datetimes and timedeltas. In the current implementation at least, the same implementation pretty elegantly works for both.

Here are some issues that I though of while implementing it:

1. I implemented it as a top-level subclass of ApproxBase, so it does not support approximate comparison of tuples, lists, or dicts of datetimes and timedeltas. On the one hand, users might be surprised that something they expect to work doesn't. On the other, this is by far the simpler way, both in terms of implementation and API. In order to support a mixed list of numbers and datetimes, we would need a way of passing different tolerances for different elements, and I can't think of a way to do that cleanly. We could support iterables containing only datetimes and timedeltas, which might be a good compromise. In either case, maybe we should add an explicit type check to the constructor of ApproxScalar explaining that it is not supported.
2. I went with disallowing relative tolerances both for datetimes and timedeltas, since their interpretation is less clear (and less useful) than for numbers. A case could be made for allowing relative tolerance for timedeltas, but it's not clear what a reasonable default should be, and it breaks some of the symmetry between the datetime and timedelta cases.
3. In the current implementation, the absolute tolerance parameter must be a timedelta. I considered the idea of allowing numbers and interpreting them as a number of seconds, or adding other kwargs so we could do something like approx(expected, seconds=5), similar to the constructor of timedelta. But I think it obscures clarity and simplicity for a very marginal gain in conciseness.
4. Since there is no relative tolerance, the only parameter which is relevant to pass to approx() is abs. The sort of annoying thing is that abs is the third parameter to approx(), so we can't pass the tolerance as a second parameter without the keyword abs=. I thought of playing games with the arguments in order to switch the order, but I think it would create more problems than it's worth.
5. I didn't do a short-circuit check that the actual value is exactly equal to the expected, because the cost of the relative calculation isn't much more than the cost of the exactly equals calculation, so it will be a waste in the common case without really saving much in the worst case.
6. Should we validate the type of the actual value at comparison time? I noticed that for numeric types we don't, and the user will get the TypeError whenever it happens to arise, for example when subtracting the actual from the expected value. Should we stick with this behavior, or do explicit type checking when comparing, or at least catch the TypeError and re-raise a more indicative one? Explicit checking might be a good idea because subtracting a timedelta from a datetime will work, so comparing a timedelta to the approx of a datetime and comparing a datetime to the approx of a timedelta will raise different exceptions.