this post was submitted on 18 Nov 2023
65 points (98.5% liked)

Python

6206 readers
12 users here now

Welcome to the Python community on the programming.dev Lemmy instance!

πŸ“… Events

October 2023

November 2023

PastJuly 2023

August 2023

September 2023

🐍 Python project:
πŸ’“ Python Community:
✨ Python Ecosystem:
🌌 Fediverse
Communities
Projects
Feeds

founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] takeda 15 points 10 months ago (11 children)

Yeah, the names imply that those should be TZ aware. Though I can understand the reasoning, as this change can silently break already broken code that kind of works, and would be a nightmare to fix in a large codebase.

I also disagree with author, about naive datetime. I don't think there is a good use case for them, and people who use them, do so because they are not aware of the issues.

The only argument I saw was for micro performance improvements, which is kind of funny to care about when programming in python. Since it is implemented in C, the code removing the timezone likely takes more resources.

[–] [email protected] 7 points 10 months ago (9 children)

While it would be ideal to have all datetime fields in databases and other data stores be time zone aware, that is certainly not the case. Also, SQLite (and probably others) do not have great support for time zones and it's recommended to store datetimes as UTC (typically unix timestamps).

Deprecating utcnow was a good idea, but they should have replaced it with naive_utcnow. Oh well.

[–] [email protected] 9 points 10 months ago (8 children)

Timezones are a disease and should be eradicated. I will die on this hill.

[–] [email protected] -4 points 10 months ago (1 children)

@BeardedGingerWonder will you adapt your time to be 7 hours later?

Thought so.

[–] [email protected] 2 points 9 months ago

You thought what?

load more comments (6 replies)
load more comments (6 replies)
load more comments (7 replies)