API data for Observations Latest is 4 hours behind

[johnrb68]

API data for station latest observations is coming back 4 hours delayed.

For example the following request:

https://api.weather.gov/stations/KROA/observations/latest

for example a while ago...
"timestamp" shows "2020-04-19T12:54:00+00:00",
But it should be: 2020-04-19T12:54:00-04:00 or 2020-04-19T16:54:00+00:00

Temperature reported is also in line with what the temperature was 4 hours ago, and not the latest (current) observation temperature for this location.
Data also does not match with values show for that station on the weather.gov website.

Latest observation data is worthless if it is 4 hours old.

Please look into this.

Thank you.

[scadergit]

Please do not report operational issues (such as outages or delayed products) here. We can not support these issues via this forum. Please report these as described here: https://weather-gov.github.io/api/reporting-issues. The more reports sent, the higher priority it will get.

If the raw product included in the reponse has a different time, then please provide an example. Looking at KROA, it is correct. All times are UTC.
"timestamp": "2020-04-19T15:54:00+00:00",
"rawMessage": "KROA 191554Z VRB03KT 10SM CLR 13/01 A2998 RMK AO2 SLP151 T01280011 $"

The weather.gov website uses a different source for observation data than the API. While it is currently more accurate, it is also has far fewer stations. We're waiting on the source to improve, and it is not a bug in the API.

[johnrb68]

Everyone is passing the buck, and no one is listening. I go one place to report issues, they send me to another place, I report there, and they send me here to report.
Now you are sending me to yet another place that will most likely brush me off to someone else.
This is madness, there needs to be one central place for people to go to report issues, and there is none.

In this case, it is supposed to be the latest observations and this data should not be more than 1 hour behind at the most. Four hours is not current, so there must be something wrong.
I converted the UTC time in the most recent response to my local time, and it was for 4 hours earlier, not the current time or within 1 hour of current time. I work with API's from all over the world, and convert UTC to many numerous time zones all the time, I know the difference between UTC and local time zones. Reporting 37° F when it is 55° F is not current (converted from C to F).

You say looking at KROA it is correct, but you said 15:54 UTC, but it should have been a 19:54 UTC response to be correct 30 minutes ago (assuming update at approximately 5 minuets before the top of the hour as usual).

But I am done - if no one is ever going to listen to people reporting problems, then why bother? Nothing will ever get fixed because people will stop reporting issues because no one wants to listen to the problems. I'm not going to bother reporting any more issues.

I am abandoning the newer (it's been over 3 years now) API and will go back to using the old XML - at least it works more often than the new API with JSON.

Thanks for not helping.

[scadergit]

Sorry, I was not aware of your previous history with support. NCO has strict deligation, and the team that watches these forums are developers that do not have the authority to work or affect operational issues. We can only assist with how the API should be used. If you were told to come here by NCO support, please provide the case number and I'll assist with the miss-direction.

I agree that the latest obsevations should not be more than an hour old. I was simply stating that 19T15:54:00+00:00 in the time stamp agrees with 191554Z in the raw product (note the raw time does not include seconds, so the 19 is the date, not the hour/min, which is 15:54). That does not imply it qualifies as the most recent, just that the API is returning the only data that it has correctly.

There are underlying issues that NCO is addressing that result in observation data latency. It is understandable at this time to continue to use the XML data until they are addressed (likely by summer, as covid is impacting on-site upgrades).