Change time zone used for formatting gridmet dates

[lekoenig]

This PR addresses the second item in #159, "check date formatting for gridmet data," and changes the time zone used to format gridmet dates in p2a_met_light_data from Etc/GMT+5 to UTC.

In p2_met_data_at_obs_sites, we read in the netcdf file containing the gridmet data and subset the data to the "well-observed" COMIDs. When we read in the netcdf, R formats time as a datetime ("dttm") column:

> tar_load(p2_met_data_at_obs_sites)
> head(p2_met_data_at_obs_sites)
# A tibble: 6 x 10
    COMID time                 tmmx  tmmn    pr  srad    vs  rmax  rmin     sph
    <dbl> <dttm>              <dbl> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl>   <dbl>
1 4495680 1978-12-31 19:00:00  59.3  48.8 0.632  35.6  7.70  82.8  66.0 0.00686
2 4495656 1978-12-31 19:00:00  58.4  48.0 0.634  35.7  7.63  84.2  66.9 0.00678
3 4492036 1978-12-31 19:00:00  61.9  47.8 0.481  35.8  9.57  86.1  58.5 0.00628
4 4784831 1978-12-31 19:00:00  59.9  48.9 0.610  35.5  7.77  82.2  65.5 0.00690
5 4782619 1978-12-31 19:00:00  58.1  48.3 0.625  35.5  7.61  84.8  67.5 0.00679
6 4782585 1978-12-31 19:00:00  57.3  46.7 0.610  36.0  7.57  88.8  69.0 0.00673
>

I previously thought the gridmet dates were being read in and assigned a datetime using EST by default. However, taking a closer look, I think this should be changed to UTC. The gridmet website indicates that the data begin in 1979, so I think we're currently assigning dates 1 day off from what was in the original gridmet data. @jsadler2, can you confirm that you'd expect the gridmet data to start on 1979-01-01 and end on 2022-06-12?

Here's a comparison of using EST vs UTC (see last two columns):

> library(targets)
> library(tidyverse)
> tar_load(p2_met_data_at_obs_sites)
> p2_met_data_at_obs_sites %>%
+     mutate(date_est = as.Date(time, tz = 'Etc/GMT+5'),
+            date_utc = as.Date(time, tz = 'UTC')) %>%
+     slice(1:5, (nrow(.)-5):nrow(.))
# A tibble: 11 x 12
     COMID time                 tmmx  tmmn    pr  srad    vs  rmax  rmin     sph date_est   date_utc  
     <dbl> <dttm>              <dbl> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl>   <dbl> <date>     <date>    
 1 4495680 1978-12-31 19:00:00  59.3  48.8 0.632  35.6  7.70  82.8  66.0 0.00686 1978-12-31 1979-01-01
 2 4495656 1978-12-31 19:00:00  58.4  48.0 0.634  35.7  7.63  84.2  66.9 0.00678 1978-12-31 1979-01-01
 3 4492036 1978-12-31 19:00:00  61.9  47.8 0.481  35.8  9.57  86.1  58.5 0.00628 1978-12-31 1979-01-01
 4 4784831 1978-12-31 19:00:00  59.9  48.9 0.610  35.5  7.77  82.2  65.5 0.00690 1978-12-31 1979-01-01
 5 4782619 1978-12-31 19:00:00  58.1  48.3 0.625  35.5  7.61  84.8  67.5 0.00679 1978-12-31 1979-01-01
 6 4781413 2022-06-11 20:00:00  76.7  61.2 0.331 230.   2.30 100    66.1 0.0131  2022-06-11 2022-06-12
 7 4781411 2022-06-11 20:00:00  77.0  61.3 0.289 230.   2.30 100    65.5 0.0130  2022-06-11 2022-06-12
 8 4655440 2022-06-11 20:00:00  78.3  65.7 0.232 231.   2.5   98.1  66.9 0.0140  2022-06-11 2022-06-12
 9 4650548 2022-06-11 20:00:00  78.7  62.1 0.209 229.   2.40 100    63   0.0133  2022-06-11 2022-06-12
10 4650580 2022-06-11 20:00:00  78.2  62.1 0.202 231.   2.30 100    63.9 0.0133  2022-06-11 2022-06-12
11 4652046 2022-06-11 20:00:00  78.7  64.5 0.528 231.   2.5   99.7  64.9 0.0137  2022-06-11 2022-06-12

[jsadler2]

Yes. When I pulled it, I used the dates 1979-01-01 to 2022-06-12. I'm not grasping all the details the issue, but does that answer your question?

[lekoenig]

Yes. When I pulled it, I used the dates 1979-01-01 to 2022-06-12. I'm not grasping all the details the issue, but does that answer your question?

Yes, the fix in this issue is easy and doesn't require further sifting on your part - I just needed this confirmation, thank you!