4 ms·
> I still prefer to work with naive always-UTC datetimes. Why prefer to work with naive UTC datetimes, rather than explicit UTC datetimes? What's wrong with p
by Karellen 3y ago
> I still prefer to work with naive always-UTC datetimes.
Why prefer to work with naive UTC datetimes, rather than explicit UTC datetimes?
What's wrong with plain `datetime.datetime.now(datetime.UTC)`?
- gmassman 3y agoI’m also curious to know why OP prefers naive to tz aware datetimes. IMO naive datetimes are a bad default, and `utcnow()` deserves to be deprecated.
- whalesalad 3y agoBecause many engineers decided long ago that you’d handle these concerns at the perimeter and assume UTC everywhere internally. Should and can be a decision left to the developer, no reason to take this away.
- aftbit 3y agoDatetimes are naive in my database. The fundamental problem with the change you recommend is that I cannot then compare those two different datetimes. For example, today I might do: user_over_30d_old = user.created_at < datetime.datetime.utcnow() - datetime.timedelta(30) But in the future, I would need to do: user_over_30d_old = user.created_at.replace(tzinfo=datetime.UTC) < datetime.datetime.now(datetime.UTC) - datetime.timedelta(30) Which isn't any better than the solution I proposed above, of removing UTC from the now() datetime. Alternatively, I could modify my DAL code to promote datetimes from naive to timezoned in the database at the edge of the python layer, but that would have a lot of knock-on effects in things like isoformat() now appending timezone information, which has caused issues in other broken APIs that I use.