ulmo-dev/ulmo

understanding times and timezones with ulmo.usgs.nwis.get_site_data()

Closed this issue · 6 comments

Am doing what I consider basic retrievals, but finding I can't understand the times info.

Here is an example.

dat = ulmo.usgs.nwis.get_site_data('01104500',service='iv',parameter_code='00060',
start=pd.Timestamp('1992-01-01 00:00:00',tz='UTC'),
end= pd.Timestamp('1992-12-31 23:30:00',tz='UTC'))

I seek a full calendar year of data in UTC times. (The iv temporal resolution is 30 minutes.)

The gauge is located in timezone UTC-5.

I expected the first time value in the output to be the same as the first time given as an input, but:

dat['00060:00000']['values'][0]

has '1991-12-31T20:00:00-05:00'.

Similarly, for the last time value in the output I expected it to be the same as the last time given as an input, but:

dat['00060:00000']['values'][-1]

has '1992-12-31T19:30:00-05:00'.

So it appears that ulmo is sending out times that are 1 hour ahead of the two inputs I gave it for start and end times.

Is this as expected?
If this is explained in the documentation please point me to it.
If it isn't, a brief explanation would help-- perhaps the times passed out are the end of the interval and the ones passed in are the start of the interval?

Not sure why but now I can't replicate the trouble I was having-- instead it is all making sense, I am getting out from ulmo the range of datetimes that I was expecting to get. Disregard this issue, I am closing it.

Glad to hear the problem has disappeared!

Interestingly, when I had the problem on Friday our local time here was Daylight Savings, EDT.

Then over the weekend we "fell back" so on Monday, when the problem now was no longer occurring, our local time was Standard Time, EST.

I'm not sure if this explains it, but it might.

Does ulmo.usgs.nwis.get_site_data() take in to account the local time, in the sense that it would distinguish between daylight time (such as EDT) and standard time (such as EST) of the gauge location, and give a different output in the way I think I have observed here?

Okay. I think I found the answer. The dictionary returned from the call to usgs.nwis.get_site_data() includes some metadata which indicates that its times do respect daylight savings changes.

Thanks for reporting back. Do you think you can suggest text to improve the usgs.nwis.get_site_data documentation about time zone handling?

How about just adding something like
"... dicts; time zone information for time data is included in the 'site' key"
to this?

Returns: data_dict – a python dict with parameter codes mapped to value dicts