3 ms·
Bad idea. datatime.utcnow() should be the default way of recording & storing time, e.g. in logs or in the database. All other options are strictly inferior.
by tomp 3y ago
Bad idea.
datatime.utcnow() should be the default way of recording & storing time, e.g. in logs or in the database.
All other options are strictly inferior.
>>> str(datetime.datetime.utcnow())
'2023-11-19 16:46:04.049705'
>>> str(datetime.datetime.now(datetime.UTC))
'2023-11-19 16:46:35.924671+00:00'
There's no reason for `+00:00` visual noise in the UTC-aware datetime.
- forgotpwd16 3y ago>datetime.datetime.now(datetime.UTC) There're many things to complain but this is certainly not one. datetime.datetime.now(datetime.UTC).replace(tzinfo=None) Though this should be `datetime.timezone.utc` rather `datetime.UTC` if not mistaken.
- tomp 3y agonot sure, I tried this in Python 3.11.6 and `datetime.UTC` works whereas `datetime.timezone.utc` doesn't exist in any case, just compare datetime.datetime.utcnow() and datetime.datetime.now(datetime.UTC).replace(tzinfo=None) verbosity is not a virtue in this case
- remram 3y agoThis is verbose because it is dissuaded. The whole point of this change is to not have users get naive datetime objects, of course it gets more verbose.
- int_19h 3y ago`datetime.timezone.utc` is the original way of doing it and should work just fine on a stock Python 3.11 install. `datetime.UTC` is a relatively recent addition, and if you look at the actual type of the object it returns, it's still `datetime.timezone.utc`
- forgotpwd16 3y agoSo my installation was outdated. Still not fan of having two different ways to refer to the same thing.
- remram 3y agoThere is definitely a reason...