Fix some time issues

[ldecicco-USGS]

Should now allow this:

start <- "2025-10-01"
> end <- Sys.Date()
> dataRetrieval:::format_api_dates(c(start, end), date = TRUE)
[1] "2025-10-01/2026-02-02"

(which fixes #853 )

and this:

dataRetrieval:::format_api_dates(c("2010-01-01T00:00Z", "2010-01-01T05:00Z"))
[1] "2010-01-01T00:00:00Z/2010-01-01T05:00:00Z"

(which fixes #839 )

[ehinman]

Does this need to be changed to date?

[ldecicco-USGS]

Actually, I think it should be changed to logical (because it tells the code whether or not to return a date or dateTime)

[ehinman]

Oh, I meant the input is named "date" and it is logical, right?

[ehinman]

FYI, I tried this with a lowercase "p7d" and "p7D" and the API will not have it. I don't think there's necessarily anything you need to do here, just a random test.

[ldecicco-USGS]

we can plop a toupper in there, good to know!

[ehinman]

This looks good. Approved. I particularly love this implementation:

start_end <- as.POSIXct(c("2021-01-01 12:15:00",
"2022-01-01 16:45"),
tz = "America/New_York")

dataRetrieval::format_api_dates(start_end)

Very nice.

A couple thoughts/suggestions that are optional: The function documentation for time, begin, and end don't go into detail on the range of dates that the functions will accept. Is this intentional?

In the Water Data APIs vignette, it does a few things with the time input, and there's a section that covers the time zone reference table, but it might be nice to show off using UTC offsets in an example, or the really lovely time zone example I highlight above, where you don't have to futz with offsets at all.