You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 27, 2024. It is now read-only.
If the server's zoneinfo has no information about the timezone, dateutil just raises a warning.
In this example, the server is a Debian 11 Docker container, the server does not know about CEST:
>>> import dateutil.parser
>>> dateutil.parser.parse('Tue 12 Jul 2022 10:47:47 AM CEST', fuzzy=True)
/usr/local/lib/python3.8/dist-packages/dateutil/parser/_parser.py:1207: UnknownTimezoneWarning: tzname CEST identified but not understood. Pass `tzinfos` argument in order to correctly return a timezone-aware datetime. In a future version, this will raise an exception.
warnings.warn("tzname {tzname} identified but not understood. "
datetime.datetime(2022, 7, 12, 10, 47, 47)
On other systems, CEST is known, so it's not a defect of dateutil or pytz. Maybe it depends on the pytz installation method (if installed from packages/the distribution, the distro's zoneinfo is used, otherwise the built-in timezone infos, which may have a different (smaller) data base).
I suggest to raise an error if the timezone is found, but not unterstood, i.e. converting the warning to an exception.
The text was updated successfully, but these errors were encountered:
work around certat/intelmq-webinput-csv#78
(webinput not knowing about 'CEST'/etc. timezone) by using a different
format (+02:00 syntax) and fixing the comparison step
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
If the server's zoneinfo has no information about the timezone, dateutil just raises a warning.
In this example, the server is a Debian 11 Docker container, the server does not know about CEST:
On other systems, CEST is known, so it's not a defect of dateutil or pytz. Maybe it depends on the pytz installation method (if installed from packages/the distribution, the distro's zoneinfo is used, otherwise the built-in timezone infos, which may have a different (smaller) data base).
I suggest to raise an error if the timezone is found, but not unterstood, i.e. converting the warning to an exception.
The text was updated successfully, but these errors were encountered: