4 ms·
> I don't understand why the functions weren't just made to return non-naive results. You've literally asked for UTC. I totally agree with you that it makes no
by thrdbndndn 3y ago
> I don't understand why the functions weren't just made to return non-naive results. You've literally asked for UTC.
I totally agree with you that it makes no sense this `utcnow()` does not return tz-aware object.
But I think their fix is great in this regard: now you just use `datetime.now(timezone.utc)`. It's more explicit, it returns aware DT object now, and more importantly, it gets rid of a function that I always feel too specific to have anyway (like how we don't have `plus(a, 2)` and `plustwo(a)`).
- abh123 3y agoI got bit by this once. Timezones aware date calculations can be an order of magnitude slower than non tz aware. Consider every time a legislative body changes dst, it creates an entry in the timezone database that needs to be checked when adding or subtracting time from that timezone.
- ryukoposting 3y agoThis is one of the reasons why Unix epoch time soldiers on, even though it is totally indecipherable to humans. It can be easily mapped to a timezone-aware type, but performing arithmetic on it is trivial.
- sanderjd 3y agoExcept isn't datetime.now() still going to return a tz-naive datetime? I would much rather have a method that requires an explicit tz, or explicitly uses UTC (like utcnow, but with the right return type). Looking for this mistake in code reviews gets really old.