search

csparpa / pyowm

A Python wrapper around the OpenWeatherMap web API
https://pyowm.readthedocs.io
MIT License
789 stars 171 forks source link

Which time zone is pyowm living in? #319

Closed eumiro closed 4 years ago

eumiro commented 4 years ago 
pyowm.utils.timestamps.now("iso")

on a host set to the Europe/Berlin time zone (UTC+2) returns '2020-06-19 19:45:30+00' at 19:45 of the local time (17:45 UTC), which is 2 hours off.

In the .now method it takes datetime.datetime.now(), which is a tz-naive current time in the time zone of the host (e.g. Europe/Berlin) but without this information. Then it formats it using .strftime('%Y-%m-%d %H:%M:%S+00') to a string that looks like UTC, but it is not.

There are several occurrences of datetime.datetime.now() in the code which use local time of the host without the information about where this host is located.

Time zones observing DST may also cause problems in the methods .tomorrow() and .yesterday() that are documented as referring to time = now ± 24 hours, but if you run this on a local host on a day before/after DST switch, the number will be wrong.

pyowm does not import pytz or zoneinfo, so it does not know time zones. If it lives in UTC, I'd suggest to replace all datetime.datetime.now() with datetime.datetime.now(datetime.timezone.utc). If you agree, I can prepare a PR.

csparpa commented 4 years ago

Hi @eumiro ! of course, please feel free to contribute :) thanks!

eumiro commented 4 years ago

Hope the changes in #321 are okay.

In pyowm/utils/timestamps.py there's a lot of usage of date local variable that covers the imported date module, but I didn't want to introduce breaking changes. Maybe the datetime.date could be imported as another alias.

csparpa commented 4 years ago

Thanks @eumiro ! it's on the develop branch, will be released soon