pirateweather
pirateweather copied to clipboard
Pirate-Weather
Querying yesterday BUG - '"Invalid Time Specification"'
Describe the bug
get an '"Invalid Time Specification"' when using -86400 in the time section to see yesterdays data
Expected behavior
see yesterdays data
Actual behavior
Error: "Invalid Time Specification"
API Endpoint
Production
Location
US
Other details
call: https://api.pirateweather.net/forecast/{{token}}/{{lat}},{{long}},-86400?units=us
Troubleshooting steps
- [X] I have searched this repository and Home Assistant Repository to see if the issue has already been reported.
- [X] I have read through the API documentation before opening this issue.
- [X] I have written an informative title.
I need a tag for "forgot to implement". Thanks for bringing this to my attention, and I'll get it added back in shortly.
As an aside, on of the biggest improvements in V2 is that this sort of query should be much more accurate. In V1, it just took the previous day's forecast; however, in V2, it's now using the analysis data for the previous 36 hours to generate these
@alexander0042 I tested yesterday and the only time option which worked was using a UNIX timestamp. All the other options came up with that same error message.
I could change my flow hitting this API to grab current UTC timestamp and subtract 86400 and provide that. Would be easier if i could always specify -86400 but up to how you want to implement.
Can confirm passing a UTC timestamp does work
Good news and bad news. The good news is that I fixed the bug preventing this, which was a pretty easy fix (type error). The bad news is it led me to another (possible) glitch, which might be a bit trickier to solve.
As things stand, every 6 hours I ingest the previous 36 hours of data plus the forecast. This was done with the idea that I need data starting from midnight of the current day, plus a buffer, so the farthest back that could ever be needed was -24, so this gave a bit of a buffer. However, to get accurate results for the previous 24 hours, I really should be ingesting back to -60 hours. I've set it so that everything "works" now, and returns data; however, it might not quite capture the full time period. In particular, if you request -86400 at 23:00 hours. accumulations for the previous morning might not be included in the response.
I'm going to fix this in 2.1, but since it's part of the ingest side of things, it's a larger change that will take a bit longer. In the meantime though, you shouldn't notice anything major using 2.0.6
V2.1 is releasing today which brings some fixes to this. @alexander0042 is this issue good to close?