> Still, this feature is not appealing enough to try to squeeze into 3.7 release schedule.  I think this should go through a round of discussion either on datetime-sig or python-ideas.

Agreed. I will put together some summary in the next week or so and send it to one of those (probably python-ideas, I guess).

> Why not start with that?  Remember: python standard library is where code goes to die.  By implementing this feature in dateutil you will not be tied to relatively slow python release schedule.  Of course, you cannot change datetime.now from a 3rd party module, but you can provide your own dateutil.now with the desired features.

This is sort of independent of whether it is implemented in `datetime`, but it's a bit more complicated than that. I have already, for example, implemented a `today()` utility that does what `datetime.today()` should do if it weren't leaking implementation details from how `date.today()` is implemented (i.e. gives you the current date at midnight), because I think that's a very common use.

The reasons I brought this here are:

1. I would *prefer* it if what I implement is more or less in line with what is implemented in the standard library if a standard library solution is going to be provided so that my `dateutil` function is more of a version-independent backport than a "second way of doing things", so the direction that Python is going can inform how I choose to implement my `dateutil` backport.

2. The solution in `dateutil`, which provides functions and classes that manipulate `datetime`, will likely be different from how it is handled upstream, so it's worth having a discussion about what to do in the standard library - the standard library, for example, can overload existing operators on `datetime`, provide alternate constructors, or modify the arguments to existing alternate constructors. The semantics of this are somewhat different from a `dateutil` function that constructs a datetime (for example, there was a lot of discussion in `dateutil.utils.today` about what the function should be called - it would be cleanly namespaced if it were `datetime.today()`, but `today()` seems like it might return a `date`, etc).

For something like this, where `dateutil` is acting more like `boltons` in that it is providing little convenience functions and extensions to the `datetime` library, I think it makes sense to see whether this might get an implementation upstream and what that implementation might look like upstream, even if what happens is that I go off and implement something similar in `dateutil` and we give it a year or two in `pip` to see what problems arise.

I'll also note that even though `dateutil` has a less constrained release schedule and gets to backport features from later Python versions (allowing for earlier adoption), it's widely-used enough that I'm not very comfortable making backwards-incompatible releases. As a result, once an interface is released, it's more or less set, so it's more or less just as important to get this right in dateutil as it is in datetime.