Pirate-Weather / pirateweather

Code and documentation for the Pirate Weather API
Apache License 2.0
617 stars 27 forks source link

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

Open Scags104 opened 1 month ago

Scags104 commented 1 month ago

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

alexander0042 commented 1 month ago

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 commented 1 month ago

@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 commented 1 month ago

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 commented 1 month ago

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