Change `datetime` behaviour in `get_vpts()`

[PietrH]

Suggestion is that if a single timepoint is provided instead of an interval, only data that matches this datetime as closely as possible should be returned.

For daily resolution: the closest available day
For hourly resolution: the closest available hour
For minute, and second resolution: a single row of the vpts file.

However, we want to avoid returning data too far away from the timestamp, so there should be some reasonable rounding/ceiling-floor logic. Perhaps, within 20 minutes or so? Like if no data is found within 20 minutes, return an error?

Intervals should always be within the interval. If one end of the interval does not have data (for example, the upper bound is in the future), then the existing data should be returned. If nothing exists in the interval, return an error.

Discussed with @peterdesmet, @CeciliaNilsson709 and @bart1. Please add on to this if I got anything wrong!

[bart1]

I think it would more logical to no make separate logic for hours, rather if it is a date return the full day, if it is a time the lowest time before the time with a max of say an hour or so. For an interval indeed everything that falls in the interval. I'm only not erroring when no pvol can be found in the interval, you just get an empty list

[PietrH]

What about if you want multiple rows returned, you need to enter an interval, if you enter a timepoint, you get a single row, using a floor to match to the closest one.

If we can't find one within the hour, we can return an empty object with a warning?

[bart1]

Here is a potential test I just encounterd :

expect_identical(
get_vpts(
  radar = c("nlhrw"),
  datetime = as.POSIXct((c("2025-03-22 23:55:04"))),
  source = "baltrad"
),
get_vpts(
  radar = c("nlhrw"),
  datetime = as.POSIXct((c("2025-03-22 23:55:05"))),
  source = "baltrad"
))