A personal weather site often stores the visitor’s unit choice and language in a cookie so millimeters stay millimeters on the next page. European rules of the late 2000s also asked operators to tell visitors when a site stored or accessed information on their machine. Those two facts collided in PHP templates. The historical TNET “eucookie” project sat on that collision.
This article describes the engineering tension: preference state versus a consent notice, on hobby weather templates, as a documentation problem. It is not legal advice, not a compliance kit, and not a download of the old snippet. It is distinct from a later Weather Display–oriented pack at a dotted path (/projects.eucookie.pkgs.wdtemp). Modern TNET Weather does not offer cookie-law services and does not maintain Cumulus templates.
Historical context
Cumulus sites were frequently PHP on shared hosting, visited by people in more than one country, and written by operators who were trying to publish temperature, not run a legal department. Templates commonly used cookies or similar storage for:
- Units — Celsius or Fahrenheit, hPa or inHg, millimeters or inches.
- Language — a translated chrome around the same numbers.
- Display preferences — which panel is open, whether a graph is shown.
Those cookies are not weather. They are browser state that changes how an observed number is labeled. The number in realtime.txt is still the station’s packet. The cookie only chooses the conversion and the words.
In parallel, Directive 2002/58/EC (the ePrivacy Directive), as amended by Directive 2009/136/EC, set EU-level rules on storing or accessing information on a user’s terminal equipment, with information and consent conditions and limited exceptions for storage that is strictly necessary to provide a service the user requested. The consolidated legal texts are on EUR-Lex for 2002/58/EC and EUR-Lex for 2009/136/EC (last checked 13 August 2026). Member states implemented the directive in national law, so the operational details were not uniform. Later instruments, including the GDPR, changed the wider privacy landscape after many of these PWS templates were written. None of that is interpreted here.
What the historical project had to do, as software, was give a template a place to declare that cookies existed, what they were for, and how a visitor might refuse or continue. Community weather scripts of that period often shipped a banner or policy include because forum templates had started asking for one. The named-package catalog records eucookie as that documentation wrapper.
The engineering tension
Three requirements pull in different directions. A template author can satisfy one by breaking another.
The weather must remain readable. If refusing a cookie blanks the temperature, the site has turned a preference mechanism into a paywall on public observations. Unit conversion can be done without storage: a query string, a form that lasts for one request, or server-side defaults that match the station’s native units. Storage is a convenience, not a physical requirement of showing a thermometer.
The preference must survive navigation. Operators wanted /gauges and /graphs to keep the same units. That is exactly what a cookie is good at. It is also exactly the behavior that a notice has to describe. A silent unit cookie is still storage on the terminal. Calling it “just settings” does not change the technical fact.
The notice must not lie. A banner that says “we use cookies to improve your experience” while the only cookies are units=C and lang=en is vague. A banner that lists advertising networks the template does not include is also a lie. The honest documentation is a short inventory: name, purpose (units, language), first-party or not, and whether the page works with the cookie absent.
The tension is therefore: document the real cookies, keep observations visible without them, and do not pretend a unit preference is a weather measurement.
This page does not tell you whether a unit cookie is “strictly necessary,” whether implied consent was ever enough, or what a given national authority expects in 2026. Those are legal questions for the operator and, if needed, a qualified advisor in the relevant jurisdiction. Historical community snippets were not a substitute for that then and are not a substitute now.
What belongs in a weather-template cookie inventory
A useful inventory is a table the operator can keep next to the station notes.
| Name (example) | Purpose | What it is not | |---|---|---| | Units preference | How to label the packet | Not a new observation | | Language preference | Chrome around the numbers | Not a translation of the climate record | | Session or consent flag | “Notice was shown” | Not permission invented by silence if your counsel says otherwise | | Third-party analytics | If present, name the vendor | Not part of Cumulus |
If the template later added a map tile provider, a font CDN, or an advertising include, the inventory changes. A cookie notice frozen in 2010 while the template grew trackers is stale documentation—the same class of failure as a stale realtime file.
Distinguish storage types in the inventory as well. A cookie, localStorage, and a URL parameter are different mechanisms. Rules that mention cookies in everyday speech often cover a wider set of terminal storage. Describe what the template actually writes.
Preference cookies are not climate metadata
Station units in Cumulus configuration are part of the observed record’s metadata: they say how the logger stored the number. A visitor cookie that converts that number for display is derived presentation. If you archive screenshots of the website for climate work, record which unit the station used, not which unit a browser last requested. Mixing those is how a Fahrenheit station becomes a fake Celsius time series in a scrapbook.
The dayfile appendix has the same lesson at file scale: the dayfile’s numbers follow the station’s configured units and locale. A PHP skin that reprints them in another unit must say so.
Distinct from the Weather Display pack
A later dotted path on this host, /projects.eucookie.pkgs.wdtemp, names a Weather Display template-oriented cookie package. Weather Display and Cumulus are different stacks, with different file contracts and different template families. This slash URL is the Cumulus-side documentation problem: notices on sites that also set preference cookies. It does not steal that child’s WD-specific contents and it does not claim the two packages were the same bytes.
Practical checklist (engineering, not legal)
- List every write to the browser the weather template performs. If you cannot list them, the notice cannot be accurate.
- Make the default rendering work with storage empty so observations remain public.
- Label converted units as converted. The packet remains the source.
- Do not copy a generic e-commerce banner onto a PWS template that has no cart and no ad network.
- Do not treat this article, or an old PHP include, as current law. Read the official texts and current national guidance, or get advice. Last checked for the EUR-Lex links: 13 August 2026.
- Retire recovered snippets that inject markup from query parameters. A cookie banner is a common XSS costume.
Modern relevance
Unit and language preferences still exist on station sites and on any service that shows weather-related numbers to a global audience. The honest pattern has not changed: say what you store, keep the measurement usable without the preference, and do not confuse presentation with observation. How a given operator meets current law is outside this article.
TNET’s public pages distinguish observed, modelled, and derived information. A unit cookie is derived presentation. It does not belong in a source inventory as if it were a sensor.
TNET research bridge
Documentation quality—knowing what a system stored, and labeling derived presentation as derived—is the same discipline TNET states for public records in how the service works. That page is about evidence families, not cookie law. The Cumulus projects map places this helper among integrations rather than among Cumulus internals. The Cumulus legacy hub lists related historical pages.
Sources
- Directive 2002/58/EC (EUR-Lex) (last checked 13 August 2026)
- Directive 2009/136/EC (EUR-Lex) (last checked 13 August 2026)
- Cumulus Wiki: TNET Cumulus Scripts (last checked 13 August 2026)
- TNET: how the service works