Sign inRegisterCheck connection

Cumulus dayfile.txt as a Daily Climate Appendix

Cumulus dayfile.txt as a daily climate appendix: one row per day of max, min, and rain, how parsing differs from realtime.txt, and monthly-summary provenance.

Back to Cumulus weather software guides

dayfile.txt is Cumulus’s daily climate appendix: one row per day, with maxima, minima, rainfall, and related fields that accumulated as the software grew. It is the file a monthly climatological table should be built from. It is not realtime.txt, not a homemade high-frequency log, and not an official NOAA climate product.

The historical TNET “PHP (No Database) Dayfile.txt Parser” read that appendix on a web host and printed summaries without a SQL server. This article is about the file’s role, how parsing it differs from parsing a live packet, and why monthly summaries need its provenance. It does not rehost the parser. Modern TNET Weather does not maintain Cumulus and does not issue climatological certificates from hobby dayfiles.

Historical context

Steve Loft shortened “daily summary file” to dayfile. The Cumulus Wiki dayfile page describes it for both Cumulus flavours (last checked 13 August 2026): a text file in the data folder, CSV-style, one line per day, created when Cumulus first needs to store a line. The field separator may be comma, semicolon, or another locale-dependent character. Field counts grew from a small core to several dozen as versions added gust, pressure, rain rate, averages, wind run, solar, UV, and other columns. MX is stricter than legacy Cumulus 1 about consistent date separators, decimal characters, and field counts across every line.

Daily extremes that feed a new line are tracked during the day (in today.ini and related state) and appended at end of day. Spot samples between logging intervals can miss a true peak; the Wiki is explicit that the accuracy of daily extremes depends on the interval between the spots used. That is an instrument fact. A PHP table that prints “max temp” is printing a software-derived daily extreme from observations, not a separately certified climate normal.

Operators who wanted those rows on a website had to get a copy of the file onto the web server. The Daily Summary wiki page discusses extra-web-file and end-of-day upload patterns for MX and older workarounds for Cumulus 1. The TNET parser assumed the file was already there. The Wiki TNET scripts list names it; Saratoga’s legacy page still offers a CU-dayfile parser as a text file under Saratoga’s notices (last checked 13 August 2026). Living upstream is Saratoga’s, not this hostname’s.

Parsing a dayfile is not parsing realtime.txt

The two files share a family resemblance—plain text, Cumulus, units the station was configured for—and they are different instruments.

| | realtime.txt | dayfile.txt | |---|---|---| | Shape | One line, overwritten | Many lines, appended | | Cadence | Seconds to a few minutes when enabled | One row per meteorological day | | Typical use | Live banner, heartbeat, snapshot | Monthly tables, historic extremes | | Missing data | A hole in a high-frequency series | A missing day, a short line, or a bad extreme | | Locale | Script-friendly decimals in the classic layout | Separator and decimal follow locale; MX is fussy | | Evidence type | Current observed packet (if fresh) | Historical daily appendix |

A parser that splits on spaces and maps Cumulus realtime field numbers onto a dayfile row will silently misread rain as temperature. A parser that assumes comma separators will merge columns in a locale that uses semicolon. A parser that assumes every historical line has the current MX field count will shift columns on old rows. Version the schema. Record the Cumulus flavour and build that wrote the file.

realtime.txt is optional and off by default. The dayfile is part of Cumulus’s climate memory. Treating them as interchangeable “Cumulus text” is the most common provenance error in inherited PHP.

What a daily row is scientifically

A dayfile line is not a 24-hour time series. It is a summary of a day:

  • Observed extremes — highest gust, highest and lowest temperature, highest and lowest pressure, highest rain rate, and similar peaks the software was tracking, each with a time of occurrence when the format includes those times.
  • Accumulations — rainfall total for the day, wind run, sunshine duration or solar integrals when those sensors and fields exist.
  • Derived daily values — mean temperature and similar calculations the software stored, which are not independent sensors.
  • Times — clocks for the extrema, which belong to the station’s meteorological day, not necessarily civil midnight. The Wiki points at meteorological-day settings and today.ini for that boundary.

Plotting a dayfile as a smooth curve through the day is the wrong figure. The right figures are daily max/min bars, monthly rainfall sums, and tables. High-frequency shape belongs to a realtime log or to Cumulus monthly logs, not to this appendix. The JPGraph article is about the high-frequency figure; this page is about the daily one.

Provenance for monthly summaries

A “monthly climatological summary” on a PWS site is only as good as the dayfile it summed.

Completeness. If three days are missing, the monthly rainfall total is not the month’s rain; it is the rain on the days that have rows. Official daily climate archives flag missing days. NOAA’s GHCN-Daily program is built on that discipline (last checked 13 August 2026). A hobby table that silently omits missing days trains readers to treat 27 rows as 31.

Siting and units. The dayfile does not know if the thermometer sat over asphalt. It does know the units Cumulus was set to. A parser that reprints millimeters as inches without a stated conversion produces a derived table that looks official. Label conversions.

Not GHCN, not NWS. A PWS dayfile is a station-software appendix. It is not a WMO climate normal and not an NWS monthly climate report. For official climate, use NCEI and the national service. For warnings, use NWS.

Backup. The Wiki’s backup note is part of provenance: MX keeps a limited number of dated backup folders on the same device. A web copy uploaded at end of day is a second copy with a different failure mode (FTP) and a different success (off-box). The PHP parser reads whichever copy the operator pointed at. Document which.

Edits. Dayfile editors exist in both flavours because rogue extremes happen. An edited row is still historical, but it is no longer “exactly what the logger appended that night.” If you publish monthly records, note when the file was amended.

Practical checklist

  1. Copy the header contract. MX documents fields in dayfileheader.txt for the installed build. Use that, not a remembered 2008 column list.
  2. Detect the delimiter and decimal from the file, then parse. Do not hard-code comma.
  3. Do not pad missing fields with zero. Zero rain and missing rain are different.
  4. Filter by the date column for a month. Do not assume line number equals day of month.
  5. State the station units and location on the table. The file does not carry a full metadata record by itself.
  6. Keep the live packet out of the monthly sum. Noon realtime.txt is not a daily max.

Modern relevance

Cumulus MX can chart historic values from the dayfile internally. Community PHP that prints a no-database monthly table is still answering a real question: show the appendix without standing up MySQL. The scientific duties did not move. Completeness, units, meteorological day, and “this is not an official climate product” still belong on the page.

Anyone migrating Cumulus 1 dayfiles into MX should read the Wiki’s migration notes on format fussiness before trusting a parser written for the older tolerance.

TNET research bridge

A monthly summary is a derived table from historical daily rows. Whether those rows are usable later depends on source identity, completeness, and units—the same questions TNET states for public records in data sources, quality controls, and methodology. That research page does not parse dayfiles, and this page does not describe TNET internals.

Related pages: the projects map, JPGraph figures, and realtime log accumulation. The Cumulus legacy hub lists the cluster.

Sources