TypeError: Cannot convert tz-naive Timestamp, use tz_localize to localize

[MichaelHopwood]

The get_observation_values method appears to be malfunctioning.

from solarforecastarbiter.io import api

access_token = api.request_cli_access_token(user, password)
query_agent = api.APISession(access_token)
query_agent.get_observation_values(query_UUID, "2/10/2021", "2/12/2021")

~\solarforecastarbiter\io\utils.py in wrapper(*args, **kwargs)
    452                         pass
    453             sig.bind(*nargs, **kwargs)
--> 454             return f(*nargs, **kwargs)
    455         return wrapper
    456     return decorator

~\solarforecastarbiter\io\api.py in get_observation_values(self, observation_id, start, end, interval_label, request_limit)
    716             If start or end cannot be converted into a Pandas Timestamp
    717         """
--> 718         out = self.chunk_value_requests(
    719             f'/observations/{observation_id}/values',
    720             start,

~\solarforecastarbiter\io\api.py in chunk_value_requests(self, api_path, start, end, parse_fn, params, request_limit)
   1607         data_objects = []
   1608         request_start = start
-> 1609         if end - start.tz_convert(end.tz) > pd.Timedelta(request_limit):
   1610             # Recurse toward the beginning of the requested period to avoid
   1611             # needing to sort the result.

pandas\_libs\tslibs\timestamps.pyx in pandas._libs.tslibs.timestamps.Timestamp.tz_convert()

TypeError: Cannot convert tz-naive Timestamp, use tz_localize to localize

This seems to have been the focus of #179. Yet, I am seeing it when using the latest version:

solarforecastarbiter          1.0.11

[wholmgren]

Thanks for the issue report @MichaelHopwood. While the title suggests a similarity, #179 and associated PRs were focused on empty observations and forecasts. The API requires users supply ISO 8601 date times. The solarforecastarbiter python API wrapper loosens the requirement to anything that can be converted into a pandas.Timestamp. Perhaps we should add a timezone check to solarforecastarbiter.io.utils.ensure_timestamps. At the very least we should make the documentation consistent.

[MichaelHopwood]

I think it's sufficient to just update the parameter descriptions for start and end in get_observation_values (and potentially other functions with similar parameters) to mandate the timezone definition. Right now, the description is a little vague.

For those viewing, simply mandating the timezone resolved the query issue:

from solarforecastarbiter.io import API

# Specify!
user = ''
password = ''
query_UUID = ''

start = pd.Timestamp("2/10/2020", tz='US/Pacific')
end = pd.Timestamp("2/11/2020", tz='US/Pacific')

access_token = api.request_cli_access_token(user, password)
query_agent = api.APISession(access_token)
data = query_agent.get_observation_values(query_UUID, start, end)

data.head()
##                           value  quality_flag
##timestamp                                     
##2020-02-10 08:00:00+00:00    0.0            18
##2020-02-10 08:01:00+00:00    0.0            18
##2020-02-10 08:02:00+00:00    0.0            18
##2020-02-10 08:03:00+00:00    0.0            18
##2020-02-10 08:04:00+00:00    0.0            18

If time permits, I think it'd be really helpful to include simple tutorials on some of these fundamental implementations. Cool library!

[wholmgren]

If time permits, I think it'd be really helpful to include simple tutorials on some of these fundamental implementations. Cool library!

Check out notebooks in https://github.com/SolarArbiter/workshop