utcnow() and utcfromtimestamp are semi-deprecated functions *because* they
do not return tz-aware datetime objects
Is this documented somewhere? Should that be reflected in the docs https://docs.python.org/3/library/datetime.html? Is there a game-plan to make it actually-deprecated instead of semi-deprecated?
On Mon, Apr 15, 2019 at 5:23 PM Paul Ganssle firstname.lastname@example.org wrote:
utcnow() and utcfromtimestamp are semi-deprecated functions *because* they do not return tz-aware datetime objects and because in all functions that require a time zone offset (like `timestamp`), naive datetimes are treated as *local* times.
If you want to use tz-aware datetime objects (which will have the correct behavior), you should simply pass a time zone to the `tz` parameter of `now()` and `fromtimestamp`, respectively, so:
from datetime import datetime, timezone a = datetime.now(tz=timezone.utc) b = a.timestamp() c = datetime.fromtimestamp(b, tz=timezone.utc) assert a == c
I will note that because of the way aware datetime comparison semantics works, `a == c` will be true no matter what `tz` object you pass to `fromtimestamp`.
If I rewrite your example with equivalent commands that do *not* use `utcnow`, you will hopefully see how it works:
from datetime import datetime, timezone from dateutil.tz import tzlocal a = datetime.now(tz=timezone.utc).replace(tzinfo=None) b = a.replace(tzinfo=tzlocal()).timestamp() c = datetime.fromtimestamp(b, tz=timezone.utc).replace(tzinfo=None) assert a == c
As you can see, in `a` you discard the time zone information associated with the datetime, and so in `b` it is implicitly taken to be "local time", shifting it by however many hours from UTC your local time is.
I will answer the hashability question in a separate e-mail, but I don't see how this has much to do with hashability.
P.S. Accidentally sent this to just Brock - Brock, sorry you are getting this twice.
On 4/15/19 8:01 PM, Brock Mendel wrote:
This has come up in pandas.Timestamp (which subclasses datetime). The issue is internal consistency and round-trips. Intuitively, we would expect:
a = datetime.utcnow() b = a.timestamp() c = datetime.utcfromtimestamp(b) assert a == b
but this fails. (Note: it works for `datetime.now()` with `datetime.fromtimestamp()`, though that is partially because of weird-to-me behavior of `timestamp()` for naive datetimes).
It would succeed if utcnow and utcfromtimestamp returned tz-aware datetime objects. Thoughts?
Datetime-SIG mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org://mail.python.org/mailman3/lists/datetime-sig.python.org/ The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
Datetime-SIG mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/datetime-sig.python.org/ The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/