You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the addition of instantaneous values from USGS, we need a strategy for handling data with timestamps, especially regarding synthesis.
Notes:
Timestamps can be reported in many formats (i.e., from the various data sources) with or without timezone.
Local time vs UTC
Daylight savings time. Some data follow it some do not. When converting data with daylight savings to without can cause duplicate / missing hour.
There are many cases in which the data are not collected at local time, purposefully and also by mistake. E.g., the data logger was setup with a computer in another timezone.
Ideas so far:
Assume local time if time zone is not reported.
Strip timezone
Plugins handle time conversions and/or basin3d can deal with a set of standard time formats (especially if not explicitly reported)
Convert time to UTC for basin3d core. In the "views" repo have different options for time synthesis representation, e.g. synthesize by UTC or by local time (with or without daylight savings)
Considerations:
transparency from the data source. can / should we report original time format?
Time frequencies higher than daily may need some different handling than the pandas dataframe approach for synthesis.
-- (re-)consider having the date/timestamp for the index
The text was updated successfully, but these errors were encountered:
With the addition of instantaneous values from USGS, we need a strategy for handling data with timestamps, especially regarding synthesis.
Notes:
Ideas so far:
Considerations:
-- (re-)consider having the date/timestamp for the index
The text was updated successfully, but these errors were encountered: