More specification for behaviour of target_datetime

Hi,

I was thinking about implementing target_datetime in some of the parsers, and came up with the following questions. If you let me know what you prefer, I can update comments in example parser and README to match 👍

• What is expected behaviour if target_datetime doesn’t exactly match available data?
  • example: 18:45 is requested, but data is only available in hourly segments. Return closest data point (19:00) or return None? I see that ENTSOE parser has closest_in_time_key logic that would do the former - should that be the guideline?
  • example: 18:30 is requested, but data is only available in hourly segments. Round up or down, or return None when ambiguous?
• What is expected behaviour when the parser can get some historical data, but not necessarily all? Examples: there might be data for only 2018 and not 2017; or there is data for 2018-03-01 and 2018-03-03 but 2018-03-02 is missing.
  • return empty dict, or empty list?
  • return None?
  • raise NotImplementedException?
• Is it worth implementing target_datetime if max time in the past is within 24 hours, or is it sufficient to return 24 hours’ worth of history when invoked without a target_datetime parameter?
• ENTSOE parser’s fetch_exchange always returns a list, even when returning one datapoint via target_datetime parameter. Is this required, or is it fine to return a list normally but a dict when called with target_datetime?

[jarek]

This looks fine now after #1237, I’ll close it. Thanks!

[jarek]

Okay, thanks!

To try to summarize:

• parsers can return as much data as feasible, provided it is close to target_datetime, with guideline being the amount of data returned in one HTTP request by source API
• timestamp datapoints correctly as indicated by source API
• don’t worry too much about how close is close enough, as backend will reject datapoints it doesn’t like
• when no matching data is available, return None

I think that makes sense - certainly it does for now.