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
--- catalog.py-orig 2020-10-28 00:25:15.000000000 -0700
+++ catalog.py 2022-02-11 23:45:07.145859536 -0800
@@ -9,6 +9,7 @@
from collections import OrderedDict
from datetime import datetime
+from datetime import timezone
import logging
import re
import warnings
@@ -111,6 +112,8 @@
The value with a time closest to that desired
"""
+ time = time.astimezone(timezone.utc)
+ time = time.replace(tzinfo=None)
return min(self._get_datasets_with_times(regex, strptime),
key=lambda i: abs((i[0] - time).total_seconds()))[-1]
Dunno if this is the "best" fix or if it fixes similar problems.
Also, in my code, I do : nexrad2.format(stn=stn0, date=time0) ... so that "time0" has to be UTC as well, so I might as well put the astimezone(timezone.utc) in my code anyway ...
I appreciate you running down the fix. The problem is that this function really has to be kind of naive. We really have no idea what the timezone is for the times encoded in the dataset filenames. One would hope they're in UTC, but neither Siphon nor the TDS can enforce this (they're just the filenames on disk). So the simplest API is to have the user submit time as a timezone-less datetime that matches the native timezone for the datasets.
I'm open to suggestions on robust ways to improve this, but unfortunately the problem we're trying to solve is pretty unconstrained.
Outputs :
Problem description : Perhaps filter_time_nearest should accept "offset-aware datetimes" ...
Expected output : https://thredds-test.unidata.ucar.edu/thredds/dodsC/nexrad/level2/KMUX/20220212/Level2_KMUX_20220212_063207.ar2v
Which platform : Fedora 35 !
Versions. Include the output of:
python --version
: Python 3.10.2The text was updated successfully, but these errors were encountered: