Open hongquan opened 1 month ago
Hi @hongquan, thanks for posting this issue. Interesting idea. Although, instead of a new method, it'd be cleaner to simply make add()
support timedelta
. I don't have many issues with this, as timedelta
and TimeDelta
are very similar and this could ease migration from the standard library.
Out of curiousity—do you need this because you're migrating away from datetime
, or do you have a different use case?
@ariebovenberg I have this need because I have Django application, where all timedelta is read from PostgreSQL as std timedelta
object.
Thanks for the context. Seems like a common use case.
Agree that it reduces noise in the code quite a bit:
dt.add(delta)
# vs
dt.add(TimeDelta.from_py_timedelta(delta))
One concern I do have is that dt.add(days=1)
is in some cases not the same as dt.add(timedelta(days=1))
, because the latter always assumes days are exactly 24 hours (which is not the case during DST transitions).
Because
add
can acceptDateDelta
/TimeDelta
, I think it would be nice it hasadd_py_delta
to accept stdtimedelta
object. Otherwise, we have to convert it towhenever
types before passing toadd
, which makes code verbose.