4 ms·
This is a bad change. Many applications work with naive datetimes that are implicitly UTC. The current way to get these objects is: datetime.datetime.utcn
by aftbit 3y ago
This is a bad change. Many applications work with naive datetimes that are implicitly UTC.
The current way to get these objects is:
datetime.datetime.utcnow()
Now the easiest way to get those will be this soup:
datetime.datetime.now(tz=datetime.timezone.utc).replace(tzinfo=None)
Why not just use .now()? Sometimes your code gets run on machines that have varying local times, but you still want to work with implicit UTC times. For example, when testing server code, or when writing a client application.
- Dylan16807 3y agoBut why not use explicitly UTC datetimes? You know they're UTC. Why do you want them to be naive?
- aftbit 3y agoBecause the existing codebase already uses naive datetimes. For example, perhaps there is a feature flag component that includes checks like: input_dt > datetime.datetime(2023, 1, 2, 3, 4, 5) As mentioned elsewhere, it's common to serialize datatimes without timezone because it's a huge waste of space and speed in databases and elsewhere to constantly include the timezone info. Of course you could handle this at the edge like many other kinds of serialization, but many apps exist which instead choose to keep all datetimes naive and handle TZ conversions at the edge instead.