> This can be accomplished rather efficiently by truncating a time tuple:

This will not preserve tzinfo, and (though this is not a concern unless nanosecond precision is added), I don't believe it preserves microseconds either.

That said, it's also not very readable code without a wrapper - it's not obvious that you're trying to truncate, or what level you're truncating to, just reading it. I think it's worth considering "truncate" to be a first-class operation of datetimes, since it comes up very frequently - people truncating off unnecessary microseconds from `now`, people truncating the result of `datetime.now()` to get today, people getting the beginning of a given month, etc.

Of course, then the question is just "where does this wrapper live". It can live in user code, which is probably not ideal since a bunch of people are implementing their own versions of this common operation and carrying around `utils` submodules or whatever just for this, or it can live in third party libraries like `dateutil` or `boltons`, or it can live in the standard library - where it will likely get the most optimized treatment. (And, honestly, `dateutil` would provide a version-independent backport anyway).

That said, if the answer to the above is "not in the standard library", I think it makes sense to add a precision argument to `now`, since that is probably the most common use case for this sort of truncation function - and it also makes a lot of sense to allow users to specify the precision with which they get the current time.