leppott / ContDataQC

Quality control checks on continuous data. Example data is from a HOBO data logger with 30 minute intervals.
https://leppott.github.io/ContDataQC/
MIT License
20 stars 10 forks source link

get gage data - missing initial measurements for the start date and spilling into the next day on the other end #101

Closed JenStamp closed 3 years ago

JenStamp commented 3 years ago

not sure there is any way we can address this, but when I use the 'get gage data' function, and plug in 1/1/2015, the output is missing the first set of measurements for that day (its starting measurement is 1/1/2015 5:00:00 AM). when I plug in 12/31/2015 as my end date, it spills over into the next day (its ending measurement is 1/1/2016 4:45:00 AM). if you want data for a particular date range, I'm not sure there's a way to deal with this offset issue other than manually trimming the end measurements and using the previous day (in this example, 12/31/2014) as the starting date (which I'm fine doing, I just wanted to bring it to your attention in case there's a slick fix you can come up with...but not a high priority item right now). Thanks!

leppott commented 3 years ago

Data is reported with timezone UTC (-5 hrs from eastern time).

image

https://cran.r-project.org/web/packages/dataRetrieval/vignettes/dataRetrieval.html#unit-data image

If change timezone to America/New_York get the same data with the timezone changed (and the time changed by 5 hours).

image

leppott commented 3 years ago

Not an issue with the Shiny app. The app is getting the same results as the dataRetrieval package on its own.

Need to have users be mindful of their own time zone.

It is interesting that the R package while reporting the data with UTC time zone filters the data by the local time of the gage (NC so eastern US).

image

leppott commented 3 years ago

If select a time zone other than the one with the gage still get data based on the gage's time zone. (Just like if don't select a time zone and get UTC).

image