Weather Display can publish a daily “average and extremes” HTML report: mean temperature, humidity, dewpoint, barometer, wind, plus the day’s maxima and minima with clock times. The historical file at /scripts/wdavgext/sample.php was a rendered sample of that report, titled as a month-to-date page for April 2009. It is not a live climate product and not the extractor. The extractor lives at /tws-avgext-script.php. This page is about how to read that HTML as a statistical sample: what “average” and “extreme” mean, how large a month is, and why WD layout changes broke scrapers.
A sample is not the climate
A month of station days is a sample from a process that includes weather, siting, sensor faults, and logger gaps. NOAA’s professional daily archive (GHCNd) treats each element as an observation that may carry a quality flag. WD’s average/extreme HTML is a derived view of whatever days that copy of WD has already accepted.
Implications:
- The monthly mean at the bottom of a month-to-date report is the mean of the days included so far, not a closed climatological month and not an NCEI monthly normal.
- An extreme is the maximum or minimum among those same days, with a timestamp. It is not a return-period estimate.
- A single gust of 39 mph in the sample is an observed peak in that file, not a proof that every April behaves that way.
The April 2009 capture on this URL should be treated, if at all, as a historical example of WD’s English-unit layout (Fahrenheit, inches, miles per hour), not as a current Mesa climate series. This article does not reprint the day-by-day listing. Day-level numbers without a documented quality review would look more precise than they are.
What “average” means in this report
WD’s daily average temperature is a reduction of the day’s samples according to WD’s own rule for that version—not automatically (Tmax+Tmin)/2, and not automatically a true 24-hour integral. Humidity, dewpoint, barometer, and wind averages in the same block are likewise WD-defined. Comparing them to a textbook meteorological daily mean without reading the field definition produces false discrepancies with climate2 daily tables.
Wind averages are especially easy to misread. A vector-mean direction and a scalar-mean speed answer different questions. A day with north wind in the morning and south wind in the afternoon can show a weak mean speed and a meaningless mean direction. The extreme gust with a direction and a clock time is often the more physically interpretable wind number on the page.
Rain on these reports is usually cumulative (month-to-date, year-to-date) plus a maximum short-period rate. Cumulative fields are not daily averages. If the month-to-date rain does not change for ten days, either it did not rain or the gauge stuck. The HTML will not tell you which.
Heat index printed on a cool morning is another definition trap. If WD emits a heat-index line whenever it computes one, the number may appear outside the temperature-humidity envelope where the index is meant to be used. Treat it as WD’s derived field, not as an NWS heat product. Official heat guidance belongs to the National Weather Service, not to a station HTML skin.
What “extreme” means
An extreme line typically pairs a value with a day number and a time. That timestamp is part of the observation. A maximum temperature at 15:29 is a different kind of fact from a maximum that lacks a time (which may be a daily summary without sub-daily resolution).
Outliers in a 19-day month-to-date block are not rare by construction: you have 19 daily maxima to look at. A point that fails a physical range check (humidity 11% can be real in a dry climate; humidity 0% or 150% is not) should be held out of a “monthly extreme” highlight until the sensor record is reviewed. GHCNd’s quality tests exist because extremes are where logger errors love to hide. A hobby report has no equivalent flag column, so the operator’s logbook is the flag.
Do not drop a true gust because it “looks high” without a reason (wiring, units, known firmware bug). Do not keep a 0.00-inch monthly rain if the month file shows a mid-month jump that the average/extreme HTML never picked up—that is a parser or generation-time mismatch, not meteorology.
Sample size of a month
April has 30 days. A report “up to day 19” has n = 19 for daily averages, fewer if some days are missing. Statements that need n:
- monthly mean temperature (incomplete if n < days in month);
- monthly rainfall (YTD is a running sum, not a mean, but missing days still matter if the gauge was down);
- sunshine hours month-to-date (a total, sensitive to missing sensor days).
Publishing a mean without n is how a two-day outage becomes a “cool month.” Incomplete periods must stay visible in the published table.
Leap days, station relocations, and unit changes inside the month all reduce the homogeneity of the sample. They will not be footnoted by WD’s HTML unless you add that metadata yourself.
Why extractors broke
The scripts index already recorded that WD changed the average/extreme HTML and that the TNET extractor stopped matching it. That is the HTML-as-API failure mode described for climate year files, applied to a different report.
Typical break points:
- English labels (
Maximumtemperaturerun-on, extra spaces, translated headers); - new fields inserted (solar, ET, UV) shifting column-oriented scrapers;
- time format changes (
14:39versus2:39 pm); - unit tokens moving from the value to a header;
- month-summary block appended with slightly different field names than the daily blocks.
The extractor page documents the intended include-and-call pattern and the assumption of English WD output. Use that page for the tool’s mechanics. Use this page to interpret a sample that such a tool would emit. Do not assume a community fork still matches your WD build until a private golden-file test says so.
How to use a sample like April 2009
If you keep a dated HTML report for documentation:
- Record the generation date, WD version if known, units, and station identifier.
- Separate daily averages, daily extremes, and month-to-date rollups into different tables.
- Store missing days explicitly.
- Compare one or two days against the native logger or against
climatedataout.htmlusing the climate2 disagreement checks. - Never promote the sample to a climate normal.
TNET does not rehost the GIF day-charts the old page linked (20090401.gif and the rest). Those were station images, not open data.
Averages and extremes are two of the ways atmospheric evidence gets summarized for humans. TNET’s connection outlooks likewise distinguish observed measurements from derived summaries and from forecasts. The public map of those groups is how the service works. This WD report is a station-scale illustration of the same vocabulary: an average is derived, an extreme is an observed peak inside a sample, and a month-to-date block is historical the moment the month is no longer today. Related PHP explainers sit on the legacy scripts hub.