I don't really think zoneinfo being in the stdlib has much
bearing on the question of utcnow/utctimestamp. We already had a
UTC object in the standard library, and could have made this
change any time, but chose not to because it would break backwards
I'm definitely more in favor of deprecating it than I am of changing the behavior, which would be a major breaking change and one that is hard to warn about. Removing utcnow would probably be a lot of work for a lot of people, but many people are probably using it wrong anyway so that may be a net benefit.
That said, there is at least one use case I'm concerned about where the replacement is not great:
If you want a datetime in UTC that you immediately format, attaching the `UTC` object rather than using `utcnow` would lead to a performance regression without any actual benefit (and sometimes it's actually a bit of a pain). For example:
would have to turn into:
The first of these is slower but no safer than the `utcnow` version, and the second of these actually involves stripping the UTC object from the result of `now` just to avoid `isoformat`'s behavior where it automatically appends the time zone offset to aware datetimes.
I haven't looked at it, but it may be that we can special-case `datetime.timezone.utc` in the `now()` and `fromtimestamp()` constructors so that `datetime.now(timezone.utc)` is just as fast as `datetime.utcnow()`, in which case the first example is not a huge deal, and maybe the second performance regression isn't so bad that it is worth leaving around footguns like this. It'd be nice to put some numbers on that.
Now that zoneinfo is in the stdlib, I'd like to revisit the idea of either a) making utcnow/utcfromtimestamp return tzaware or b) deprecating in favor of explicitly passing tzinfos to now/fromtimestamp.
On Mon, Apr 22, 2019 at 10:54 AM Alexander Belopolsky <email@example.com> wrote:
_______________________________________________> what if I'm in New York, but running on a JupyterLab system in Los Angeles?
In this case, it would be the responsibility of the JupyterLab designers to set the timezone of the kernel to something useful to the user. In the case of a single-user kernel that would be the user's timezone, in the case of multi-user kernels - most likely UTC or something that the users can agree upon. The location of the JupyterLab server should never be a consideration.
Setting the timezone is currently more complicated than it should be:
import sys, timesys.environ['TZ'] = 'America/New_York'time.tzset()
but I don't think we can improve that before python gets an integrated timezone database. For now, this is what you should do to make sure a remote system uses the timezone that you want.
Datetime-SIG mailing list -- firstname.lastname@example.org
To unsubscribe send an email to email@example.com
The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
_______________________________________________ Datetime-SIG mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com 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/