I may be over-stating the degree of consensus about the deprecation here. I'm not sure too many people have discussed it, but there is very little reason to ever use them, because:
1. The reason they existed in the first place was as a convenience when there were no concrete time zone types in the standard library. 2. Adding the `tz` argument to `now` and `timestamp` has provided a more general solution to the problem anyway. 3. They create objects that are inconsistent with the way Python treats naive datetimes, since naive datetimes are supposed to be abstract representations of a time, and if they need to be treated as a concrete time, they are taken to be /local/ times. The one advantage `datetime.utcnow()` has is that it is somewhat faster than `datetime.now(tz=timezone.utc)` (I clock it at 168ns vs 300ns), but getting the current time in UTC is not likely to be the bottleneck in any sort of "hot loop" situation where 300ns is going to make the difference. I think deprecating them would be nice, but it would break backwards compatibility to actually /remove/ them, so I'm maybe +0 on that. I'd say at the very least documenting that these things have a good replacement would be a good idea. Maybe we should make a bpo issue (and possibly PR) for this. Best, Paul On 4/15/19 10:32 PM, Brock Mendel wrote: > > 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] > <mailto:[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 <http://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] >> <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[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] > <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[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/ >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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/
