Personal weather websites syndicated conditions the same way blogs syndicated posts: an RSS document that machines could poll. The historical path /RSS/rss-feed.php was that generator on the original TNET Weather site. HTML told a visitor it was 72°F. The feed was supposed to tell a program the same fact with a timestamp, units, and enough identity to know which station produced it.
This page is the contract: which fields a station feed must make explicit, how PWS sites used RSS to share current conditions, and the hygiene failures that made those feeds unusable. The companion article at /index.rss is about the document on disk—content-type, caching, and how a consumer should parse a well-known feed path. Do not treat the two URLs as duplicates. One is the schema. The other is the file.
Why a station needed a feed at all
A PWS homepage mixed observations, forecasts, webcams, and navigation. Scraping it for temperature is brittle. RSS existed so aggregators, mesomaps, and other station sites could subscribe without rendering HTML. Weather Display and Cumulus both had ways to emit or update XML; community PHP often wrapped the current conditions as a single-item channel that changed in place rather than accumulating news items.
That design is closer to a status document than to a weblog. The channel still needs the required RSS 2.0 elements (title, link, description) documented by the RSS Advisory Board. The scientifically load-bearing content lives in items and, when used, namespaced extensions.
A useful station item answers five questions:
- What was measured?
- In which units?
- At what instant, in which timezone?
- Where is the station (latitude, longitude, and preferably elevation)?
- Is this an observed value, a forecast, or a phrase derived from other fields?
If any of those are missing, the feed is a brochure, not an observation contract.
Items, units, and identity
RSS 2.0 allows an item to be complete in itself: title or description must be present; everything else is optional. Optionality is convenient for news and fatal for weather. A consumer that sees <description>Wind 12</description> cannot know whether that is miles per hour, metres per second, or a Beaufort number, or whether it is a two-minute average or a gust.
Put units in the payload, not in an out-of-band README. Prefer one item that represents the current observation set over a dozen items that look like a blog history. If you do emit multiple items (hourly snapshots), give each a stable guid so aggregators do not treat an edited temperature as a new event. The RSS specification’s guid rules exist exactly so processors can decide “same item, updated” versus “new item.”
Coordinates belong in the contract because temperature without location is not climate. Store decimal degrees with an explicit hemisphere or sign, and state the datum if you know it—typically WGS 84 for a GPS-derived station, which is not automatically NAD 83. Conversion and error magnitude are covered on station geodesy. Do not bury lat/lon only in HTML <img> map URLs.
Channel-level pubDate and lastBuildDate are RFC 822-style timestamps per the RSS spec. Station feeds should treat lastBuildDate as “when this XML was generated” and item pubDate as “when the observations were valid.” Those two instants are often minutes apart. Collapsing them hides stale-file problems.
How PWS sites actually syndicated conditions
Typical amateur practice was:
- Weather Display or Cumulus writes a local conditions file on a schedule.
- PHP reads that file and prints RSS.
- Other sites poll every 5–15 minutes and paste the description into a sidebar.
That loop works only while the publisher and the consumer share assumptions: English labels, the same unit system, and a clock that means the same thing. It fails as soon as one side switches WD to metric, a host emits dates in local time without a zone, or a cache serves yesterday’s XML with today’s HTTP 200.
Saratoga Weather’s script catalog includes RSS-related utilities and, more importantly, an explicit warning that scripts must be configured for a particular station (Saratoga scripts). Official Weather Display documentation describes custom web pages and uploads, not a universal feed schema. There never was a single PWS RSS standard. The contract has to be local and documented.
Feed hygiene
These checks belong in the generator, not in a later apology.
Timezone. RSS dates follow RFC 822 with a numeric or named offset. Tue, 13 Aug 2026 14:54:00 without a zone is not a timestamp. Station local time without the offset cannot be compared to NWS products, which are typically referenced to UTC or a named local zone. If the logger is in US Mountain Time, say so in the date, and say whether daylight saving is applied.
Stale entries. A feed that still validates as XML can be hours old. Compare file mtime, lastBuildDate, and the observation time inside the description. If the station should upload every five minutes and the file is two hours old, the honest item is a gap, not the last good temperature. Do not recycle the previous guid with new prose that claims “current.”
Escaping. RSS is XML. An anemometer label Wind < 5 mph, an ampersand in a station name, or a degree character in the wrong encoding will break parsers. Use XML escaping or CDATA consistently. Serve UTF-8 and declare it. HTML entity soup inside description is allowed by RSS but is a second parser for the consumer; keep the observation fields in plain text if you want machines to use them.
Missing fields. Omit a field or use an explicit missing token. Do not publish 0 for a failed sensor. Zero rain can be real; zero humidity is not.
Forecast leakage. Canned WD forecast strings and NWS zone text are forecasts. If they appear in the same item as temperature, label them. Mixing them taught aggregators to treat model language as a station observation.
Polling ethics. A feed is cheaper than scraping HTML, but it is still a request budget. Set ttl (minutes) if you use RSS 2.0’s optional element, and honor it on the way out with HTTP caching as discussed for the feed document. Do not point a mesomap at rss-feed.php?debug=1.
What a consumer should demand
Before you subscribe a station feed into a map or a research table, require:
- a documented field list and units;
- an observation timestamp distinct from the HTTP date;
- coordinates that survive a round-trip to decimal degrees;
- a statement of what happens when the logger is down;
- a license or at least a clear reuse note for the values (many PWS sites never stated one).
If those are absent, use the feed only as a human headline. NOAA’s NCEI archives show what a real observation record looks like: identity, time, element, units, and quality flags. A hobby RSS item will never match GHCNd, but it can stop being ambiguous.
TNET’s public explanation of how structured inputs are grouped—without publishing proprietary forecast assembly—is how the service works. Station RSS is the amateur-web ancestor of that idea: a machine-readable snapshot that is only as good as its timestamps, units, and coordinates.
The scripts hub collects related PHP explainers. None of them replace an official warning product; when the item text includes a watch or warning, the authoritative source is the local National Weather Service office, not the station feed.