Handle new wind variables in API

[Aariq]

While testing code in #39, I noticed it seems like there are some new columns in the hourly data on the API that are causing a couple tests to fail. I can modify code/tests accordingly, but are these new columns here to stay?

az_hourly() |> select(starts_with("wind_2")) |> colnames()
#[1] "wind_2min_spd_max_mph"  "wind_2min_spd_max_mps"  "wind_2min_spd_mean_mph"
#[4] "wind_2min_spd_mean_mps" "wind_2min_timestamp"    "wind_2min_vector_dir" 

[jeremylweiss]

Nice catch! We just added "wind_2" data fields this afternoon to both hourly and daily data. These are permanent columns. We have yet to start updating the datalogger program at individual stations, so values right now in the database should be 'nodata' values.

This is good to know for any future addition of variables to the database.

[Aariq]

Looks like to handle these we'll need to

1. Convert wind_2min_timestamp to a datetime (currently converted to NAs by as.numeric())
2. Double-check that they are picked up by az_add_units()

[Aariq]

This is where the warnings are coming from:

azmetr/R/az_daily.R

Lines 83 to 86 in 61582f9

	dplyr::mutate(dplyr::across(
	c(-"meta_station_id", -"meta_station_name", -"datetime"),
	as.numeric
	)) %>%

[jeremylweiss]

wind_2min_timestamp values now come in as type 'character'

[jeremylweiss]

use of lubridate::with_tz() with your earlier code of lubridate::parse_date_time() seems to fix this