Guess start and end date when no time bounds are available

[dougiesquire]

With this PR, when no time bounds are available in a file, a guess of the start and end dates are made based on the first and last time and the frequency.

@aidanheerdegen, @utkarshgupta95 this is definitely a yucky hack, but it should fix #113 and #114.

Closes #113, closes #114

[codecov]

Codecov Report

Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (f7ca779) 97.31% compared to head (4024c97) 97.31%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #116      +/-   ##
==========================================
- Coverage   97.31%   97.31%   -0.01%     
==========================================
  Files           9        9              
  Lines         522      559      +37     
==========================================
+ Hits          508      544      +36     
- Misses         14       15       +1     

Files	Coverage Δ
src/access_nri_intake/source/utils.py	98.49% <98.24%> (-0.47%)	⬇️

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jo-basevi]

Hi Dougie, Aidan suggested that I have a look at this PR as I have done some similar date calculations with date-based restart pruning in Payu. From what I can tell, the changes all look good to me!

I'm unfamiliar with the xarray data (so I might not be the best person for this review sorry!), is the time data points normally at the start or end times, or is it impossible to know if there isn't known bounds? Just wondering if its better to have end/start times to be either +/- the frequency rather than half the frequency either side of start and end times.

[dougiesquire]

Thanks heaps @jo-basevi!

is the time data points normally at the start or end times, or is it impossible to know if there isn't known bounds? Just wondering if its better to have end/start times to be either +/- the frequency rather than half the frequency either side of start and end times.

I don't think it's possible to know where the time point is, unfortunately. However, I think the assumption that the time point is at centre of the averaging period makes the most sense. This is indeed the case for the data in the issues that motivated this PR (#113, #114).

[dougiesquire]

RTD build is now failing. This PR does not update the docs, and I've opened an issue here #118, so merging