The weather API answers with a measured present and a forecast future in one response. This page explains how the two are kept distinct, and why the one-word summary of the sky is decided on the server.
Now is measured. The rest is forecast.
current comes from the surface weather stations around the point: airfield
observations, mesonets and CWOP stations. It is not the model’s opinion of the
present. A model’s analysis hour is still a forecast however recently it ran,
and there is usually a thermometer within a few miles that is not guessing.
hourly and daily are the National Blend of Models. The two are never
blended together and they can disagree, which is not a bug: an observation is a
fact about this minute and a forecast is a guess about the next one.
Both start where the reader is standing in time: hourly[0] is the hour
containing server_time and daily[0] is today at the forecast location. A
cycle’s series really begins in the past (NBM runs every hour and its first
step is an hour after the cycle behind it) and that reach-back is cut off so
that a strip can be drawn straight from the array. GET /forecast serves the
same series whole, past hours included, for clients charting a run rather than
displaying it.
station names the instrument the reading is attributed to: the one that
supplied most of the fields. Where it has no sensor for something, the next
station nearby fills that field silently. For example, a backyard station with
no visibility sensor gets its visibility from the airfield 6 km away.
current is null when no station within 50 miles has reported in the last
two hours. That is a different statement from every field coming back empty,
and it is deliberate: a reading from an airfield 200 miles away is a true
reading and a false claim about here.
current.sky and current.icon are the exception to “measured”. No station
reports total cloud cover, so they come from the forecast hour nearest
server_time. is_day is not borrowed: it is the sun’s position at this
instant and this point.
For the unsimplified answer, every field credited to its own instrument, use
GET /conditions. current is that endpoint’s
answer reduced to flat numbers and one name.
One word and one picture for the sky
The store publishes numbers, not prose, so the wording is derived. It is derived on the server rather than in each client on purpose: the underlying inputs are four independent precipitation type probabilities that do not sum to 100, a cloud fraction and a thunder probability, and two panels in one house deriving their own answers is how they end up disagreeing about the same hour. The words and icons, and the thresholds behind them, are listed in Sky words and icons.
icon is the same decision as sky, made as a picture. A client supplies
artwork for the eleven icon names and nothing else.
Day and night come from is_day, which is the sun’s position at that hour and
place rather than the clock, because “day is 6 to 6” is wrong for months at a
time in Alaska. Days carry no is_day and their icon is always the daytime
one: a card for Thursday showing a moon would say Thursday is night.
If you want the inputs rather than the conclusion (the four type probabilities
separately, CAPE, ceiling, the severe weather parameter) those are on
GET /forecast, which serves every field the models
publish. The weather endpoint is the reduction.