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.
Thoughts? On Mon, Apr 22, 2019 at 10:54 AM Alexander Belopolsky < [email protected]> 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, time > sys.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 -- [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/
