I want naive datetime objects. I want them to be unknowable because I want them to be unalterable.
I don't want some silent function in the middle of something somewhere to "help" me by changing my datetime objects to the timezone I "obviously" mean.
I want to be in charge of my own data representations.
@davidr it's usually a bad idea, and it shouldn't be a problem which timezone is attached to your object, as long as there is one, but a datetime without a timezone is meaningless, the whole point is that it's never obvious what timezone it is, no one should have to guess if it's UTC, or the system's timezone, or the timezone of the user at the time they sent it, i agree timezone-naive datetimes are a bad enough idea python should actively discourage using them.
At least using the stdlib.
@davidr If you want to be in charge, you can certainly build your own lib, or use one of the existing alternatives, If you want to do everything with timestamps that are implicitely UTC and only convert to python datetime when necessary, a few functions should do the trick, but really, time is messy and using naive objects is really asking for trouble.
@tshirtman Using "naive" (i.e. unmarked and therefore universal) datetimes has always worked perfectly for me and any attempt to add timezones, even utc, has always broken something somewhere.
This idea is 'helpful" in the sense that garbage UIs are helpful: they think they know what I want better than I do and actually make my life harder.
@davidr the idea that a "naive" datetime is "universal" makes no sense to me.
I told you X happened on 2023-11-10 at 18:30:32. what does it mean?
If I didn't tell you what timezone it is, that can mean many different actual timestamps.
Adding timezone support to an app that doesn't have them can be troublesome, but only because the app makes assumptions, and uncovering them shows bugs.
Ensuring your app never works with any naive timestamps is a lot better way to avoid issues.
@tshirtman I deal with space data. It is always and forever utc, period.
If there's no tz attached, "helpful" libraries cannot try to move that time to "local". If there is a tz attached, I 10000% guarantee they will. And my code will break.
@davidr I think we have a disagreement about what it means for a datetime to have a timezone, and to "change" it. Having an explicit timezone means nothing has to guess, it's there, and it makes the time universally understood, and "changing" the timezone, is only a matter of changing the representation of that particular datetime, i.e, to display it to a human in a way that's useful to them.
I'd be really curious about cases where a tz-aware datetime gets its tz changed, let alone silently.
Add comment