-
-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Concerns with time format in get-consumption-data response: clarification/disambiguation needed #5
Comments
Well, this is actually how Datadis returns the data, I agree it is a horrible design but it goes as follows: time: 01:00 -> Consumption from 00:00:00 to 00:59:59 So, for example, 2023/05/15 24:00 consumption data is just consumption from 2023/05/15 23:00:00 to 2023/05/15 23:59:59 And then you have 2 exceptions caused by DST (daylight saving time):
Knowing this (which is from poorly to non-documented by Datadis), an API wrapper should not fix this horrible design, its job is to facilitate API calls and give the responses without manipulation. Then it is up to the program that uses this API wrapper to make the necessary transformations. |
Thank you for such a quick and well written reply. It seems I was indeed being dull indeed--I lost focus on the fact that the values referred to time periods. In any case, your reply is very clarifying, thanks! By the way, I don't know what's the contribution policy on the repository, but your reply could be part of the documentation on this particular issue almost verbatim. |
Anyone is open to contribute in any of my repositories 😄 |
First of all, thanks to the authors for this very useful and interesting library and API.
Perhaps I'm being dull, but I believe that there might be an issue with the format in which time is expressed, specifically in the
get-consumption-data
API call response.Lets consider a response, given in the following format:
{'(...) 'date': '2022/10/01', 'time': '01:00', (...)}
For a day inside the given period, there are several observations at the hour mark, beginning at the 01:00 mark and ending at 24:00. This makes me doubt whether "24:00" of date "2022/10/01" corresponds to:
OR
If the case is the former, why not use 00:00 outright? If it is the latter, the format which is being used can lead to confusion, as the date given inside the response is not the actual date the time value refers to.
Furthermore, most of time-related data types or in most databases that I know of time can only be inputted from "00:00" to "23:59", thus leading to potential compatibility issues.
I've looked through the documentation and haven't found any information regarding this issue.
Thanks in advance! Keep up the good work!
The text was updated successfully, but these errors were encountered: