Weather Display uploaded more than one climate HTML file. The historical TNET Weather script at /scripts/climate2 parsed climatedataout.html—a daily-within-month (and related) layout—while climate1 parsed climatedatayearout.html, a year-scale summary. Two parsers, two files, one station. When their numbers disagree, the wrong reflex is to pick the prettier table. The right reflex is a short forensic checklist: units, year definition, and how trace precipitation was stored.
This page is not a replay of the recovered daily grid, and it is not a second copy of the year-file article. It is about robustness: HTML versus CSV/XML, and what to run when extracts diverge.
Two WD climate exports are not duplicate views
climatedatayearout.html is organized around months of a year. climatedataout.html, in the historical workflow, exposed daily rows for a month: maximum, minimum, and average temperature, dewpoint, wet-bulb, degree-day style fields, sunshine, snow, water equivalent, barometer, wind, and daily extremes. Those are different aggregations.
If the year file’s monthly mean temperature is not a function of the daily averages in the month file, you may be looking at:
- different generation times (WD rebuilt one HTML and not the other);
- different averaging rules (mean of daily means versus mean of all logger samples);
- a partial month in one file and a closed month in the other;
- a parse error in one extractor.
The historical climate2 page even showed a table of daily fields with dashes for unused future days. That pattern is a clue, not a dataset to republish. Unused trailing days are missing, not zero. A parser that averages the dashes as empty strings coerced to 0 will pull a monthly mean toward freezing or toward zero rain.
HTML versus CSV versus XML
Among publication formats a station might emit, robustness ranks roughly like this:
XML or another schema-bound export. Element names carry meaning. Missing values can be attributes. Units can be attributes. Layout changes are less likely to shift “column 7.”
CSV or other delimited text. Column order can still shift, but a header row is a contract. Quoting is specified. You can hash the file. NOAA NCEI distributes GHCNd in structured text with explicit quality flags (GHCNd product page; daily readme). That is the professional version of “put the climate in a table.”
HTML. Headers are visual. Cell count is a layout accident. Language-specific labels break regexes. WD’s own format changes already retired the historical climate1 scraper. Climate2 is the same class of tool aimed at a different filename.
If WD (or a later logger) can write CSV, parse that. Keep HTML as a human view. If you only have HTML, pin a golden fixture and fail tests when headers move.
Saratoga’s current-conditions templates read clientraw.txt and tag files (WD template setup), which is closer to a delimited contract than to climate HTML. Climate summaries never got the same community standardization. That is why two in-house parsers on one site could disagree.
A disagreement protocol
When the year parser and the month-day parser (or an average/extreme report) disagree, run these checks in order. Stop when you have an explanation; do not average the two answers.
1. File time and software version
Compare FTP timestamps and, if available, the WD version that wrote the files. A year HTML uploaded at 00:10 and a month HTML uploaded at 00:40 can differ on the last day’s rain. That is not a climate signal.
2. Units
A 32 versus 0 disagreement in temperature is often °F versus °C on the same physical day, or a parser that stripped the unit and then compared across files. Pressure 30 versus 1016 is inches of mercury versus hectopascals. Wind 10 versus 8.7 may be mph versus knots.
Do not convert until both sides have a labeled unit. A silent default of “the station is in Arizona so it must be Fahrenheit” will eventually meet a metric WD install.
3. Calendar year versus water year
U.S. Geological Survey surface-water practice defines a water year as 1 October through 30 September, named for the calendar year in which it ends (USGS explanation). A “2024 total rain” in a hydrology table is therefore not the rain from 1 January 2024.
Weather Display climate HTML is typically a civil calendar, but operators sometimes retitle pages “rain year” or reset annual rain on an arbitrary date. If parser A sums January–December and parser B sums October–September, annual rain will not match and should not match. Label the interval before comparing totals.
4. Trace rain
NWS climate services define a trace of liquid precipitation as less than 0.005 inch—below the smallest measurable amount in that product (NOWData FAQ). Forecast discussions often treat 0.01 inch as measurable. Parsers see T, 0.00, 0, empty, and 0.0 and collapse them.
Consequences:
- Summing traces as zero undercounts days with precipitation even when the monthly total is correctly 0.00 inch.
- Summing traces as 0.005 invents rain the gauge did not measure.
- Comparing a file that preserved
Twith a CSV that wrote0looks like a 0.00-inch discrepancy that is actually a type mismatch.
Keep trace as a separate state. When you must plot a number, plot the measurable total and a count of trace days beside it.
5. Mean versus extreme versus sample
Daily average temperature in climatedataout.html is not the midpoint of that day’s max and min unless WD defined it that way. The average-and-extreme HTML discussed at /scripts/wdavgext/sample.php is yet another reduction. A monthly mean of daily means can differ from the mean of all sub-daily samples. Disagreement here is often definitional. Read the WD field name; do not assume climatology textbook definitions.
6. Missing days and dashed cells
If one parser skipped dashed future days and the other coerced them, monthly averages diverge. Count n of valid days and print it. Official daily-to-monthly pipelines at NCEI start from quality-controlled dailies and then aggregate (GSOM/GSOY). Hobby HTML has no QFLAG column; your n is the substitute.
7. Language and labels
The average/extreme extractor notes on the scripts index already warned that English WD HTML was assumed. Climate2 is equally language-sensitive. A translated “Max Temp” header means column indexes that were “working” are now bound to the wrong statistic.
What the recovered climate2 table is not
The Wayback body contained a processed climatedataout.html table with daily temperatures, winds, and placeholder dashes. Those figures are not reproduced here as a climate record. They lack a verified station identifier on that capture, a quality-flag layer, and a guarantee that the parser aligned columns with headers after WD layout changes. Quoting them as Mesa climate would confuse a historical page dump with an observed series.
If you have the original HTML from your own station, parse it under the checklist above and archive HTML plus CSV together.
Practical choice
For a living station, stop adding HTML scrapers. Export structured climate, or compute monthly statistics from the native daily file with an explicit missing-data rule. For preservation of an old site, one documented parser per filename is enough, plus a note of the WD build it last matched.
Publication of a clean table after a successful parse remains the climate1 script.php problem. Comparison across filenames is this page’s problem. The scripts hub lists both.
When two evidence streams disagree, TNET’s public research stance is to inspect definitions and quality rather than to blend them into a single unexplained number. The grouping of those streams is described in evidence families. Hobby climate HTML is a small, sharp case of the same rule.