search

DOI-USGS / dataretrieval-python

Python package for retrieving water data from USGS or the multi-agency Water Quality Portal
https://doi-usgs.github.io/dataretrieval-python/
Other
159 stars 37 forks source link

Allow user to work in timezones besides UTC #3

Open thodson-usgs opened 5 years ago

thodson-usgs commented 5 years ago

All data is converted to UTC; however, some users might prefer to work in a local timezone.

jjkennedy commented 3 years ago

Is it possible to only pull the date column from groundwater levels? I'm finding that some sites do not have a time associated with the measurement and it's throwing an error because it can't convert that to a datetime index.

elbeejay commented 1 year ago

To update the status of this issue:

At this time there is still no built-in functionality for getting queries back in whatever timezone you want, they do come back with UTC-localized timestamps.

mishranurag commented 1 year ago

I assume that the daily data is in local time zone. However, the label on the time has Z on it which can be confusing.

image

thodson-usgs commented 1 year ago

That's a bug alright. The REST API can accept time zones, so perhaps we could handle this better. https://waterservices.usgs.gov/rest/IV-Service.html Unsure what users will want as the default behavior in this case. I vote for UTC as default, otherwise there could be unexpected consequences. Having no default would leave the data in multiple time zones, which isn't ideal. Neither can we assume a default time zone based on the compute clock, because the user may be in a different time zone from their compute.

wzell-usgs commented 1 year ago

On the subject of UTC - Is it expected behavior that the returned datetime index is UTC +0 rather than local UTC? E.g., for a randomly selected GW site with IV service, here is the dataRetrieval result (UTC+0):

dataRetrieval

and here is the NWIS web interface 'view data' (UTC-6):

webdata

I think can programmatically convert to local UTC using the tz_cd with the site information but perhaps it is preferred to have dataRetrieval handle that conversion?

thodson-usgs commented 1 year ago

Correct, we decided to stick with USGS, unlike the web interface. The reason being what is "local time" when you're working analyzing data from multiple timezones?