-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ActivityStartDateTime, time zones, and offset cols #558
Comments
I like the idea of a separate time zone code column. As you note, this seems like it would be much less likely to impact existing workflows. |
From Laura D: Just making sure we're both on the same page: In dataRetrieval, the default timezone is UTC set here: Like this: library(dataRetrieval) pHData2 <- readWQPdata(siteid = "USGS-04024315", So what you are asking for is a column that converts the offset number of hours to the timezone it was converted to? Note there's also the link in the help to the OlsonNames() base R function which talks about how R handles timezones. The issue is that different operating systems and depending on where in the world the computer things you are will want different abbreviations for timezones (that's why using the OlsonNames is what has been working best for dataRetrieval). |
Is your feature request related to a problem? Please describe:
The time zone associated with ActivityStartDateTime is not clear because it is not included in the df returned from dataRetrieval:::create_dateTime, which is run within dataRetrieval functions called within TADA_DataRetrieval and separately within TADA_AutoClean when ActivityStartDateTime is missing from the input df.
Describe the solution you'd like:
I think it might be more user friendly to include a column titled ActivityStartDateTime.TimeZoneCode (UTC in this case) instead of the ActivityStartTime.TimeZoneCode_offset (which includes number of hours). As is, the target time zone for ActivityStartDateTime (a function input here) is not documented anywhere in the returned df (see review_TADAProfile1 below).
Describe alternatives you've considered:
Alternatively, UTC could potentially be included in ActivityStartDateTime but that might break people workflows (e.g. "2023-05-11 11:45:00 UTC").
Additional context:
Regarding dataRetrieval:
The internal code is here;
https://github.com/DOI-USGS/dataRetrieval/blob/main/R/importWQP.R#L223
(you can call it, you'd just need to do a triple colon: dataRetrieval:::create_dateTime)
offsetLibrary is a dataframe saved in sysdata.rda
You can see where and how it gets called here:
https://github.com/DOI-USGS/dataRetrieval/blob/main/R/importWQP.R#L160
Review_TADAProfile1 below. See discussion #557
The text was updated successfully, but these errors were encountered: