This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author p-ganssle
Recipients barry, belopolsky, p-ganssle, tim.peters, vstinner
Date 2018-01-09.16:33:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1515515599.6.0.467229070634.issue32522@psf.upfronthosting.co.za>
In-reply-to
Content
@Barry I don't think it's a good idea to duplicate the `replace` functionality in `datetime` like that. I think the main problem isn't the `.replace`, it's the fact that you have to specify exactly which components you want to set to zero - to get "the beginning of this month" or "today at midnight" or "the beginning of the current hour" or "the beginning of the current minute", you have to manually replace a whole list of these components.

It doesn't help that `datetime.today()` leaks implementation details from `date.today()`, thus making it a slower, worse version of `datetime.now()`, since the overwhelmingly most common use cases for datetime rounding are probably "get today at midnight" and "get the current time with second precision". Still, I think a more general fix would be better now and in the future.

Even if we had "get today at midnight" and a `microseconds=0` argument to `datetime.now`, without a more general version of this, if (or possibly *when*) nanosecond precision is added to `datetime`, you'd now start having to add `microseconds=0, nanoseconds=0` or something to `datetime` (depending on the implementation of nanoseconds).
History
Date User Action Args
2018-01-09 16:33:19p-gansslesetrecipients: + p-ganssle, tim.peters, barry, belopolsky, vstinner
2018-01-09 16:33:19p-gansslesetmessageid: <1515515599.6.0.467229070634.issue32522@psf.upfronthosting.co.za>
2018-01-09 16:33:19p-gansslelinkissue32522 messages
2018-01-09 16:33:19p-gansslecreate