Closed dfulu closed 1 year ago
Merging #193 (c82257f) into main (2263cd7) will increase coverage by
0.34%
. The diff coverage is93.33%
.
@@ Coverage Diff @@
## main #193 +/- ##
==========================================
+ Coverage 81.92% 82.27% +0.34%
==========================================
Files 124 127 +3
Lines 5102 5268 +166
==========================================
+ Hits 4180 4334 +154
- Misses 922 934 +12
Impacted Files | Coverage Δ | |
---|---|---|
ocf_datapipes/training/common.py | 95.54% <86.79%> (-4.46%) |
:arrow_down: |
ocf_datapipes/transform/xarray/standard_dropout.py | 94.11% <94.11%> (ø) |
|
ocf_datapipes/select/select_loc_and_t0.py | 95.65% <95.65%> (ø) |
|
ocf_datapipes/transform/xarray/nwp_dropout.py | 97.56% <97.56%> (ø) |
|
ocf_datapipes/load/gsp/utils.py | 100.00% <100.00%> (ø) |
|
ocf_datapipes/select/__init__.py | 100.00% <100.00%> (ø) |
|
ocf_datapipes/select/select_live_t0_time.py | 100.00% <100.00%> (ø) |
|
ocf_datapipes/transform/xarray/__init__.py | 100.00% <100.00%> (ø) |
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more
Pull Request
Overview
SelectLiveT0TimeIterDataPipe
due to deprecationDetail
np.datetime64
which, as far as I can gather, is unaware of timezones and instead is measured a seconds since the UNIX epoch.The tests where we slice xarray datasets using
datetime.datetime(..., tzinfo=datetime.timezone.utc)
where we explicitly state the timezone were causing an error such as :The fix is to remove the explicit timezone info for the slicing. As far as I am aware, all of our datasets are expressed in UTC, so this should not be a problem.