`epirange` interface does not support `time_value=*`

[dshemetov]

[brookslogan]

I think you can just provide "*" instead of an epirange; do you think this is usable enough?

[dshemetov]

Ah, I see. Maybe we can make the docs clearer about what epirange_like means? I thought it required an epirange object, but this looks like it will accept any character or numeric value as well. Why even have epirange if we just let people bypass it with character strings?

[brookslogan]

Definitely. Maybe we could have an "epirange_like" help topic on how to specify date and week ranges and link to it, and it could explain each of these possibilities.

Character string: this might be for "*" or for single values so you don't have to do epirange(nohyphen_datestring, nohyphen_datestring). But not sure if it also lets you use hyphens to express ranges and/or commas for multiple values.

Why have epirange?: in my mind it would be to not have to do things like paste0(format(date, "%Y%m%d), "-", format(date, "%Y%m%d)), though we're only partway there with current epirange. (Although the real reason it was implemented might be just to mirror Epidata$range from the old non-covidcast client.)

[dshemetov]

Good idea on the help topic.

[dajmcdon]

I think this is definitely important, pre-rollout. I've been struggling with various epirange() issues that could likely be cleared up in the documentation. Among them:

• Can I do epirange("2020-01-01", "2021-01-01")? If no, there should be a convenience function to convert from this.
• What if I just want one date (like as_of = "2021-01-01")? (Maybe I can just write that, but the epidatr::covidcast() docs are not clear on this point. Neither is epidatr::epirange().)
• What if I want a list of dates? Say a range of time values but a list of as_of's?

[dshemetov]

The epirange interface could use some work for sure.

• You can't do epirange("2020-01-01", "2021-01-01"), but you can do epirange("20200101", "20210101") (this is a bug in the API)
• Some fields, like as_of are set to check_single_date, so it will only accept values like "20210101" or 20210101. Actual date objects are not supported yet.
• I added the check_date function that accepts a vector of values that satisfy check_single_date, which should handle a list of dates. But, again, actual date objects are not supported there yet.

Let's look at the API URL interface and enumerate its behaviors. Speaking strictly about the covidcast endpoint, the time_value field accepts:

• a comma-separated list of dates or ranges
  • dates are either "%Y%m%d"-formatted or "%Y-%m-%d"-formatted or "%Y%w%-formatted strings
  • ranges are either "%Y%m%d-%Y%m%d"-formatted or "%Y%w%-formatted strings
• an asterisk * to denote all time values
• soon inequalities to denote open ended ranges

The as_of field only supports a single date (well, it should, but there's a bug).