Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


>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.


not 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


`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`


So my installation was outdated. Still not fan of having two different ways to refer to the same thing.


This 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.


There is definitely a reason...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: