> 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 <[email protected]> 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 protected] > To unsubscribe send an email to > [email protected]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/ > > _______________________________________________ > Datetime-SIG mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/ >
_______________________________________________ Datetime-SIG mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/
