uh oh in convert_date_to_doyhr

convert_date_to_doyhr captures the date bounds i'd expect when tz='UTC' or standard (non-daylight savings) time.

> date <- as.POSIXct("2016-05-01 00:00:00", tz='UTC') + as.difftime(seq(22,26,0.5), units='hours')
> data.frame(date=date, doyhr=convert_date_to_doyhr(date))
                 date    doyhr
1 2016-05-01 22:00:00 122.9167
2 2016-05-01 22:30:00 122.9375
3 2016-05-01 23:00:00 122.9583
4 2016-05-01 23:30:00 122.9792
5 2016-05-02 00:00:00 123.0000
6 2016-05-02 00:30:00 123.0208
7 2016-05-02 01:00:00 123.0417
8 2016-05-02 01:30:00 123.0625
9 2016-05-02 02:00:00 123.0833

but the first hour of each new day gets assigned to the previous day when tz puts us in daylight savings:

> date <- as.POSIXct("2016-05-01 00:00:00", tz='') + as.difftime(seq(22,26,0.5), units='hours')
> data.frame(date=date, doyhr=convert_date_to_doyhr(date))
                 date    doyhr
1 2016-05-01 22:00:00 122.8750
2 2016-05-01 22:30:00 122.8958
3 2016-05-01 23:00:00 122.9167
4 2016-05-01 23:30:00 122.9375
5 2016-05-02 00:00:00 122.9583
6 2016-05-02 00:30:00 122.9792
7 2016-05-02 01:00:00 123.0000
8 2016-05-02 01:30:00 123.0208
9 2016-05-02 02:00:00 123.0417

this is a problem for mm_model_by_ply where we try to compute dates and hours:

# data.plys$date <- format(data.plys$solar.time, "%Y-%m-%d")
# data.plys$hour <- 24*(convert_date_to_doyhr(data.plys$solar.time) %% 1)
> data.frame(datetime=date, doyhr=convert_date_to_doyhr(date), date=format(date, "%Y-%m-%d"), hour=24*(convert_date_to_doyhr(date) %% 1))
             datetime    doyhr       date hour
1 2016-05-01 22:00:00 122.8750 2016-05-01 21.0
2 2016-05-01 22:30:00 122.8958 2016-05-01 21.5
3 2016-05-01 23:00:00 122.9167 2016-05-01 22.0
4 2016-05-01 23:30:00 122.9375 2016-05-01 22.5
5 2016-05-02 00:00:00 122.9583 2016-05-02 23.0
6 2016-05-02 00:30:00 122.9792 2016-05-02 23.5
7 2016-05-02 01:00:00 123.0000 2016-05-02  0.0
8 2016-05-02 01:30:00 123.0208 2016-05-02  0.5
9 2016-05-02 02:00:00 123.0417 2016-05-02  1.0

because now we have three consecutive date/hour chunks (rows 1:4, 7:9, 5:6) rather than the two that would be correct.

in general solar.time will be in UTC, which is why this problem hasn't surfaced so far, but i'd better do something to either (1) guarantee it's always UTC no matter who's using streamMetabolizer and/or (2) calculate the dates and hours in a more compatible way. i think the date is what actually needs to be corrected, because DST means that 11pm really is 12am in round 24-hour periods since january 1.

DOI-USGS / mda.streams

uh oh in convert_date_to_doyhr #241