Sign inRegisterCheck connection

Migrating dayfile.txt Across Cumulus Versions

Move a Cumulus dayfile.txt from legacy builds to MX: column drift, date and decimal consistency, backup, and a dry-run before replacing the live file.

Back to Cumulus weather software guides

dayfile.txt is the file that breaks quietly when Cumulus versions change. Columns were appended over the years; date separators and decimal characters that Cumulus 1 tolerated become errors in MX. Migrating the file is a backup, inventory, dry-run, and swap. This dotted URL, /projects.phpdayfile, is that procedure. It is not an essay on what a dayfile is scientifically.

The climate-appendix reading of the file—one row per day of max, min, and rain, and why that is not realtime.txt—is the slash twin, dayfile.txt as a daily climate appendix. The historical TNET “PHP (No Database) Dayfile.txt Parser” assumed the file was already on the web host. This page is about making the file safe to move before any parser sees it. Modern TNET Weather does not maintain Cumulus and does not certify hobby dayfiles as official climate.

Historical context

Steve Loft shortened “daily summary file” to dayfile. The Cumulus Wiki dayfile page describes it for both flavours (last checked 13 August 2026): a CSV-style text file in the data folder, one line per day. The field separator may be comma, semicolon, or another locale-dependent character. Cumulus 1 accepted 15 to 45 fields as versions added columns.

MX is stricter. From some functionality in 3.4.5 and for all functionality from 3.9.5, MX reads the whole file into a RAM array with a fixed element count. Early MX was more tolerant of Cumulus 1 files; later releases expect consistent date separators, decimal characters, and HH:mm time stamps. The migration wiki page is the primary procedure source for C1 → MX (last checked 13 August 2026).

The Wiki TNET scripts list names the PHP parser; Saratoga still offers CU-dayfile parser 0.12 as text (last checked 13 August 2026). A parser written for 2010 column counts is not a migration tool. Living upstream for missing fields is the maintainer utility CreateMissing, not this hostname.

Inventory the file you have

Before you copy anything onto an MX box, describe the file you actually hold. Do this on a copy.

Delimiter. Comma, semicolon, or pipe. Mixed delimiters across years mean mixed locales or mixed PCs. MX wants one delimiter consistent with the locale it runs under.

Decimal character. Point versus comma. Cumulus 1 followed Windows region settings and could leave a mix if the PC moved. MX expects every real number to use the same character. A line with 21,4 next to a line with 21.4 is not ready.

Date field. Cumulus 1 allowed /, -, or . between day, month, and two-digit year. MX expects the separator defined for the locale, on every line.

Time stamps. Extremum times must be HH:mm with a colon on MX. Seconds or dots in old rows have to be edited or the line will error.

Field counts per line. Count tokens on the first line, a middle year, and the last line. A 2006 row with 15 fields and a 2019 row with 45 fields is normal for C1 and a problem for a strict MX release. Do not pad missing fields with zero. Zero rain and missing rain are different. Trailing separators without values are a different representation from a short line; know which you have.

Date order. Lines must be in ascending date order. Cumulus 1.9.3 had a bug that could store lines out of order; 1.9.4 builds 1086–1101 are the documented stable C1 end of the line for most station types.

Write the inventory in the station notes: flavour and build, delimiter, decimal, date separator, min/max field count, first and last date. That sidecar is provenance.

Backup before any rewrite

The Wiki’s backup note is operational, not sentimental. Daily extremes in this file are finer than what you can reconstruct from monthly logs if the logging interval is long. MX keeps a limited number of dated backup folders on the same device (on the order of the last nine restart backups). Cumulus 1 kept up to eight. Same-disk copies do not survive a dead SD card.

Copy dayfile.txt off the logger to a second device before you run any utility. Copy today.ini, the monthly standard logs, and Cumulus.ini in the same bundle: CreateMissing reads records-began date, meteorological-day start, and units from Cumulus.ini, and it rebuilds missing dayfile fields from monthly logs. Name the backup with the date and the Cumulus build, not dayfile-old.txt.

Do not edit the live file while MX is running if you intend MX to reload it. CreateMissing’s own note: you can run the utility without stopping MX, but you must stop and start MX (or use Reload dayfile where the release provides it) before MX picks up a replaced file.

Column drift is not a parser bug

Treat field-count change as a schema migration.

Cumulus 1: any line with 15–45 fields was acceptable. MX: each release expects a particular count. Forum posts mention an inadvertent extra pair of fields that were later removed; at MX 3.7.0 the documented structure was 52 fields, including humidex, after a feels-like expansion around 3.6.0. Field counts can change again. Do not hard-code 52 in a script and call the migration done. Read dayfileheader.txt for the installed MX build, and use the CreateMissing build that matches that CumulusMX.exe. The utility uses DLLs from a specific release. The wrong CreateMissing on the right dayfile is still the wrong tool.

CreateMissing will add missing fields and missing days from monthly logs. It will not overwrite values already present. That is deliberate: operators edit rogue extremes, and you do not want monthly-log spots to smash those edits. If a daily maximum is wrong, fix it in the dayfile editor after the structural migration, as a separate amendment. The amending dayfile wiki page is the editor reference (last checked 13 August 2026).

PHP parsers that assume comma separators, or that assume every historical line has the current MX width, will shift columns on old rows. Migration first, website table second.

Dry-run, then swap

  1. Work on copies in a scratch folder. Never point CreateMissing at the only copy.
  2. Align Cumulus.ini with this station’s units, meteorological day, and records-began date.
  3. Run CreateMissing against the copies. Read its report; fix monthly-log issues on copies and re-run. The GitHub README is the current flag list (last checked 13 August 2026).
  4. Diff the new data/dayfile.txt against your backup: line count, first/last date, and a sample of known extrema. Check that existing values were not overwritten.
  5. Confirm delimiter, decimal, and HH:mm on every line of the output, not only the tail.
  6. Stop MX. Replace the live dayfile. Start MX. Confirm it loads without a line-number error. MX cites the first bad line; check the following lines for the same defect.
  7. Only then copy a web-host edition for a PHP table, if you still want one. The logger’s data/dayfile.txt remains canonical.

If the dry-run output disagrees with a known extreme, stop. Do not swap.

Practical checklist

  1. Inventory delimiter, decimal, date separator, times, and field-count range on a copy.
  2. Off-box backup of dayfile, monthly logs, today.ini, and Cumulus.ini, named with build and date.
  3. Read the MX build’s dayfileheader.txt; obtain the matching CreateMissing.
  4. Dry-run on copies; diff extrema; do not pad zeros by hand.
  5. Stop MX, swap, start, confirm load.
  6. Record amendments separately from structural fills.
  7. Do not use a 2010 PHP parser as a migration engine.
  8. Keep the live realtime.txt packet out of this file. Noon snapshots are not daily maxima.

Modern relevance

MX historic charts read the in-memory copy of the dayfile. A migration that silently shortens lines or changes units will plot a different climate than the C1 screenshots you remember. Anyone moving a data folder onto a new MX release still needs backup, inventory, dry-run, and swap.

A monthly summary is a derived table from historical daily rows. Whether those rows survive a version change depends on schema identity—the same class of question 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 slash climate-appendix article, the projects map, JPGraph install, and the Cumulus legacy hub.

Sources