Support precise date ranges

[victorlin]

Description of proposed changes

This has more flexibility than ambiguous dates in reduced precision which are limited to the range of a single calendar year or month.

Related issue(s)

• Closes Allow precise date ranges #1304

Checklist

• Automated checks pass
• Check if you need to add a changelog message
• Check if you need to add tests
• Check if you need to update docs
• Merge base PR Use standard date parsing logic for subsampling (and general improvements) #1775

[codecov]

Codecov Report

❌ Patch coverage is 77.77778% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.26%. Comparing base (c2c8a51) to head (4193f87).
⚠️ Report is 3 commits behind head on master.

Files with missing lines	Patch %	Lines
augur/dates/__init__.py	77.77%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1770   +/-   ##
=======================================
  Coverage   74.25%   74.26%           
=======================================
  Files          82       82           
  Lines        9052     9061    +9     
  Branches     1847     1849    +2     
=======================================
+ Hits         6722     6729    +7     
- Misses       2024     2025    +1     
- Partials      306      307    +1     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[joverlee521]

Changes LGTM. My only suggestion is to clearly document the supported formats for date intervals since that will dictate the outputs for augur curate format-dates in #1494

[victorlin]

Note: this format is unsupported during subsampling for the same reason as #844: subsampling doesn't use get_numerical_date_from_value, but instead has its own date parsing logic where only YYYY-MM-DD is supported. I'll look into swapping that with get_numerical_date_from_value.

[victorlin]

#1774 should be resolved before this is merged, so that the new format is supported by subsampling in augur filter.

[victorlin]

As mentioned in #1304 (comment), this should be merged and released alongside #1828 which needs some more work.

[jameshadfield]

For what it's worth, I don't think we need to wait until #1828 is ready to merge this -- that's been sitting in review for 6 months and I'm guessing will be there for at least a few more. While the linked comment is correct that no existing pipelines would (currently) benefit from this, were it to be released then users could add manual bounds if they so desired.