Fabio Manganiello on Nostr: fully agree on that. And that’s apparently the current stance of the #Python ...
fully agree on that. And that’s apparently the current stance of the #Python community as well - dt.now(dt.UTC) forces the user to always specify the offset.
But all the versions of Python before 3.12 had the opposite approach. now and utcnow would always give you offset-naive objects unless you passed a tzinfo. I had a hunch that at some point things had to change, and that migrating would have been painful, but I guess that I’m realizing only now how painful it’s going to be.
And btw I’ve never understood why dt.now(), still to this day, always returns an offset-naive datetime. Like how hard it is to just fetch the tzinfo from the machine and fill it up? Literally all Python’s issues with datetime comparisons would have never existed had this approach been taken from day 1.
But all the versions of Python before 3.12 had the opposite approach. now and utcnow would always give you offset-naive objects unless you passed a tzinfo. I had a hunch that at some point things had to change, and that migrating would have been painful, but I guess that I’m realizing only now how painful it’s going to be.
And btw I’ve never understood why dt.now(), still to this day, always returns an offset-naive datetime. Like how hard it is to just fetch the tzinfo from the machine and fill it up? Literally all Python’s issues with datetime comparisons would have never existed had this approach been taken from day 1.