Skip to content
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

Querying yesterday BUG - '"Invalid Time Specification"' #221

Open
3 tasks done
Scags104 opened this issue May 9, 2024 · 4 comments
Open
3 tasks done

Querying yesterday BUG - '"Invalid Time Specification"' #221

Scags104 opened this issue May 9, 2024 · 4 comments
Labels
bug Something isn't working
Milestone

Comments

@Scags104
Copy link

Scags104 commented May 9, 2024

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

  • I have searched this repository and Home Assistant Repository to see if the issue has already been reported.
  • I have read through the API documentation before opening this issue.
  • I have written an informative title.
@Scags104 Scags104 added bug Something isn't working Needs Review labels May 9, 2024
@alexander0042
Copy link
Collaborator

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

@cloneofghosts
Copy link
Collaborator

@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.

@Scags104
Copy link
Author

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

@alexander0042
Copy link
Collaborator

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

@cloneofghosts cloneofghosts added this to the 2.1 milestone May 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: In Progress
Development

No branches or pull requests

3 participants