What a Current-Conditions Record Must Contain

A current-conditions record needs a timestamp, units, station ID, and sensor list. How to judge staleness, and how a table differs from a text bulletin.

Back to Historical weather observations and forecasts

A “current conditions” page is useful only when it is a complete observation record. Completeness is not a long list of derived indices. It is a short contract: which station produced the values, when they were observed, which sensors contributed, and in which units. Without those four pieces, a visitor cannot tell a live thermometer from a cached table, and a later archive cannot reuse the numbers.

The historical TNET Weather URL /current.php published that contract as a labeled table for a private Mesa, Arizona station. Recovered captures are historical. They are not current Mesa weather, and this page is not a live meter.

Historical context

Personal weather sites of the 2000s usually offered two current-condition surfaces. One was a graphical hub with gauges, radar, and forecast copy. The other was a dense HTML table of the latest logger fields: temperature, wind, rain, pressure, humidity, and a block of system statistics. This URL was the table.

A recovered capture dated 7 December 2012, 04:09 MST still shows why the contract matters. The page clock and a “last packet received” field in the same dump did not agree: the packet line still carried 7 December 2005, 04:09. That mismatch is the scientific lesson. Page-generation time is not observation time. A current-conditions record that cannot say which clock it used is already stale in a way the visitor cannot see.

The sister page at /get-text.php carried the same station as a linear prose bulletin. The two URLs are not duplicates. One is a field table. The other is a sentence a text browser can read aloud. Both fail or succeed by the same completeness test.

The four required elements

1. Station identifier. A name, a public network ID, or coordinates that a stranger can match to a logger. “Current weather” with no station is not an observation. If the station also published under a network ID, that ID belongs on this page; provenance is the join key, not decoration.

2. Timestamp with timezone. Prefer the time encoded in the observation packet, in a named zone (MST, UTC, or an offset). Browser paint time, FTP upload time, and “last reboot” are different clocks. If the file has no usable observation time, the honest label is that the time is missing, not that the page is live.

3. Units on every quantity. Temperature in °F or °C, wind in mph, kt, km/h, or m/s, rain in inches or millimetres, pressure in inHg or hPa. A number without a unit is not comparable to a neighbor. Dual-unit display is fine when both units are stated. A header that says “inPa” for inches of mercury is a token error; the record should use a real unit.

4. Sensor list. Which instruments produced the line: outdoor temperature and humidity, rain collector, anemometer, pressure sensor, optional solar or UV, and any indoor or specialty probes. Indoor cabinet temperature and a swimming-pool probe are valid measurements of those places. They are not outdoor air temperature. Listing the suite is how a reader knows which columns are meteorology and which are station diary.

The World Meteorological Organization treats station identity, time, and the circumstances of the observation as part of the measurement, not as optional captions (WMO-No. 8). A hobby table is not a WMO station. The same rule still applies.

Staleness is a calculated quantity

Staleness is now minus observation time, not the animation rate of the page and not the FTP interval.

A table that refreshes every thirty seconds can still show a twelve-minute-old packet. A table that never refreshes can still be a valid historical record if it keeps its timestamp. The failure mode is a page that looks current while its observation time has stopped.

Three clocks are easy to confuse on a current-conditions table:

| Clock | What it measures | What it does not measure | |---|---|---| | Sensor or radio sample | How often the instrument emits a value | Whether the website received it | | Logger archive interval | How often the station writes a climate sample | The age of the public HTML | | Page or upload cadence | How often the table was rewritten | How often the thermometer was read |

If two successive page loads hash to the same payload, or the internal observation time does not advance, no new observation arrived. Repeating the last good row without a flag is how a dead uplink impersonates calm weather. Zero wind and zero rain are legal observations. They are not substitutes for “no report.”

A defensible current-conditions page states latency in words a person can use: observation time, zone, and age. If age exceeds a stated threshold, show a gap. Do not freeze the last temperature as if the atmosphere had paused.

Observed, derived, and forecast on one table

A recovered current-conditions dump typically mixed three evidence families in one grid.

Observed. Outdoor temperature, humidity, wind speed and direction, rain totals for stated periods, station pressure (or pressure reduced to sea level if the reduction is disclosed), solar radiation if a pyranometer exists.

Derived. Dew point, wind chill, heat index, humidex, apparent temperature, estimated cloud height, fire-weather index. These are calculations from observed inputs. They are useful. They are not extra thermometers. The National Weather Service heat-index equation is a documented example of a derived apparent temperature.

Forecast. A narrative high, wind, and sky line copied from a weather service. A forecast is valid for a future interval. It is not the station’s current observation.

Historical summaries on the same page. Today’s high and low so far, month-to-date rain, year-to-date rain, and “last rain N days ago” are summaries of earlier observations. They change when the day or month boundary rolls. They are not the latest packet.

Sun and moon times, logger version, workstation memory, and packet-reception percentage are operations metadata. They help an operator debug the publishing chain. They do not belong in a climate quote unless the quote is about the logger, not the weather.

TNET’s public note on evidence families is the current vocabulary for that split: observed, modelled, and derived information must not be collapsed into one unlabeled “current” cell.

Distinct from a text bulletin

/get-text.php answers a different reader problem: encode the same record as a linear bulletin for a slow link, a text browser, or a screen reader. The bulletin’s strength is source order. The table’s strength is scanability.

The table still has to carry the contract in the cells, not only in CSS column context. A grid that shows 47.3 under an implied temperature header fails the moment the stylesheet is stripped. Put the unit in the cell or in a header that survives as text. Put the station ID and observation time above the first number.

A current-conditions table may add a last-hour strip (values at 10-minute steps) and a today’s-extrema block. Those are additional records, each with its own period: instant, 10-minute-ago sample, or daily maximum since the station’s day boundary. Label the period. “High” without “since midnight local” is an incomplete statistic.

Practical checklist

  1. Emit station ID and location before any quantity.
  2. Emit observation time with a named timezone.
  3. Compute and display latency; fail visibly past a chosen age.
  4. State units on every meteorological quantity.
  5. List the sensors that produced the columns; label indoor and specialty probes.
  6. Label derived indices as derived.
  7. Keep forecast copy in a separate block.
  8. Treat blank, missing, and zero as three different states.
  9. Do not present a recovered Mesa dump as live weather.

The station-configuration article is the metadata companion: siting and sensor suite explain how the numbers were made. The station dashboard is the information-architecture companion: how those numbers sit next to forecast and radar. The WD-Live data view is the packet-field companion: the latest file as a list, not as a styled current-conditions grid.

Modern relevance

Phones and dashboards got denser. The completeness test did not change. Archives, APIs, and connection-intelligence work still fail when “current” means a widget with no time, no units, and no station. A current-conditions record that a stranger can quote in 2032 is the same object a station owner needed in 2005: identity, time, units, and a sensor list, with staleness in the open.

Official warnings and life-safety decisions belong to National Weather Service products, not to a personal-station table. TNET is not a warning service.

Observation hub: /legacy/observations/.

Sources