Sign inRegisterCheck connection

Weather Events in iCalendar: What Belongs in an ICS File

What belongs in a weather ICS calendar: almanac times, forecast valid-times, and observed extremes, plus Google Calendar-era timezone pitfalls.

Back to Cumulus weather software guides

A calendar is a poor weather dashboard and a good log of timed events. iCalendar (ICS) can carry sunrise, a forecast discussion valid-time, or yesterday’s observed high—but only if each VEVENT is honest about which of those it is. Mixing them under one “weather” subscription is how a Google Calendar era feed taught people that a model valid-time was a thermometer. This page is the reference for what belongs in the file and how timezone encoding fails. Editorial wiki standards (cite versions, no binaries, date your maps) live on /projects.reference.wiki. This child URL is not a second style guide.

Historical context

In the 2000s, Google Calendar and other clients subscribed to HTTP ICS feeds (text/calendar). Personal weather sites experimented with “weather calendars”: moon phases, civil twilight, storm names, and sometimes a daily dump of highs and lows. The historical TNET path /projects.reference.wiki.googleical sat under the wiki-reference cluster because the work was documentation of a feed contract, not a live calendar product.

RFC 5545 is the Internet Calendaring and Scheduling Core Object Specification (iCalendar), succeeding RFC 2445. Google Calendar was one consumer among many; it is not the spec. This page uses “Google Calendar era” as the historical subscription context. TNET does not operate a weather ICS feed and does not impersonate Google.

What an ICS file is allowed to claim

Each VEVENT needs a UID, a DTSTAMP, and a DTSTART (RFC 5545). Those properties make a timed object. They do not make an observation. The SUMMARY and DESCRIPTION must carry the evidence family, the location, the units, and the source.

Almanac times (sunrise, sunset, twilight, moon)

Sunrise and sunset at a station are derived from location, date, and an algorithm (or from the station program’s almanac). They are not thermometer readings. They belong in a calendar if:

  • DTSTART is the instant of the event in a defined timezone;
  • SUMMARY says “sunrise” (or civil twilight), not “weather”;
  • LOCATION or DESCRIPTION names the coordinates or station used;
  • the algorithm or software version is cited in DESCRIPTION or in the feed’s PRODID.

They do not belong if the feed presents them as “observed sunshine start.” Cumulus packets include daylight and sunshine-related fields; those are still software products, not pyranometer proofs, unless the station actually measures solar radiation and you are calendaring that threshold crossing—and then you must say so.

Forecast valid times

A forecast is a model or office product with a valid time, not a past measurement. An ICS entry for “cold front evening” is legitimate when DESCRIPTION names the source (for example an NWS discussion) and the valid period, and when STATUS is not used to imply the event already happened. It is not legitimate when the summary is “72°F” with no “forecast” label.

Do not put official warnings in a hobby feed as if TNET or a PWS were the warning authority. Point readers to weather.gov or the responsible national service. A calendar reminder is not a Watch, Warning, or Advisory.

Observed extremes and climate anniversaries

Yesterday’s high, a monthly record, or “first freeze of the season” can be historical observations if:

  • the value, unit, and station ID are in the text;
  • DTSTART is the time of the extreme or a DATE-type all-day event for the local climate day, and the reset timezone is stated;
  • the feed does not refresh in a way that silently rewrites yesterday’s UID into a new number.

A daily high is not a timed meeting. Prefer VALUE=DATE all-day events for climate days, and DATE-TIME only when you actually know the clock time of the extreme from the logger.

What does not belong

  • A new VEVENT every five minutes for “current temperature.” That is a dashboard. Calendars do not revalidate like Cache-Control on a PNG; subscribers will accumulate thousands of events or treat updates as RSVP noise.
  • Unlabeled derived indices as if they were thermometer events.
  • Other stations’ METARs copied without attribution and without “aerodrome observation” language. A PWS banner is not a METAR.
  • Recurring RRULE weather (“rain every Tuesday”) unless you are joking in the description. Meteorology is not a weekly meeting.

Timezone pitfalls

RFC 5545 allows DATE-TIME in UTC (Z suffix), local time with a TZID parameter, or floating local time. Weather events are almost never floating: sunrise in Mesa, Arizona is not “8:00 wherever you opened the phone.”

If you use TZID, include a matching VTIMEZONE. The spec requires a VTIMEZONE component for each unique TZID used, with TZID, and STANDARD or DAYLIGHT subcomponents that include DTSTART, TZOFFSETFROM, and TZOFFSETTO. DTSTART inside VTIMEZONE must be a local date-time, not UTC with a Z. Clients that receive a malformed VTIMEZONE disagree: some import, some shift by an hour at DST, some fail.

Prefer IANA names (America/Phoenix, America/New_York) over invented TZID=US-Eastern or TZID=UTC+11. Google Calendar-era importers often trusted their own Olson/IANA database more than a homemade VTIMEZONE. If the block disagrees with the client’s DST rules, the stored event can be converted to UTC internally and then display “wrong” next spring.

UTC Z timestamps avoid a broken VTIMEZONE. DTSTART:20260813T123000Z is an instant. The client displays it in the viewer’s zone. That is correct for a worldwide forecast valid-time. It is easy to misread for “7:00 AM sunrise,” which is a local civil time. For almanac events, local TZID with a correct IANA zone is the better scientific object—if you can emit a valid VTIMEZONE or the client is known to honor the IANA name.

Arizona and other non-DST zones. America/Phoenix does not observe daylight saving. A feed that stamps Phoenix sunrises with America/Denver will be wrong for half the year. Document the station timezone as configuration, not as “Mountain Time” in English.

All-day DATE events and exclusive DTEND. RFC 5545 DATE-valued DTEND is exclusive. A one-day climate anniversary on 13 August is DTSTART;VALUE=DATE:20260813 with DTEND;VALUE=DATE:20260814, not the same date twice. Getting this wrong shifts the event in Google Calendar.

DST transitions. A “2:30 AM” local event on the spring-forward night may not exist. Observed extremes should use the logger’s stored instant, exported as UTC or as a TZID that matches the station clock policy.

UID stability. Google Calendar treats a repeated UID as an update. If your daily high event reuses one UID, subscribers see one mutating event. If you mint a new UID every upload for the same sunrise, they see duplicates. Document the UID scheme: {station}-{type}-{local-date} or similar.

Feed-level documentation

The ICS file is a product. The wiki page that describes it should state:

  • PRODID and calendar NAME/X-WR-CALNAME if used;
  • HTTP Content-Type: text/calendar; charset=UTF-8;
  • update cadence (daily almanac versus hourly is a different feed);
  • timezone policy;
  • evidence-family policy (separate calendars are cleaner than one mixed “weather” URL);
  • license of the generator, as found, without a ZIP.

Line folding at 75 octets, CRLF line endings, and escaped commas in DESCRIPTION are interoperability details. Mention them when documenting a generator; do not paste a full production ICS here.

Practical checklist

  1. One evidence family per calendar URL if you can; if not, label every SUMMARY.
  2. Almanac events: coordinates, algorithm or software version, local civil time with a real TZ.
  3. Forecast events: named source and valid time; not a PWS warning service.
  4. Observed extremes: value, unit, station, clock or climate day, historical once the day closes.
  5. No current-temperature spam events.
  6. VTIMEZONE valid or UTC Z instants; IANA TZID; exclusive DATE DTEND.
  7. Stable UID policy.
  8. Keep wiki editorial rules on /projects.reference.wiki.

Modern relevance

CalDAV, phone widgets, and “add to calendar” links still consume RFC 5545. The scientific mistake is unchanged: a timed object without an evidence label. Separate almanac, forecast, and climate-memory feeds remain the clean architecture.

TNET research bridge

TNET’s public vocabulary for observed, modelled, and derived information is how the service works. An ICS VEVENT is a good test of that vocabulary: if you cannot name the family in SUMMARY, the event is not ready to publish. Source identity and quality rules for research records are on data sources, quality controls, and methodology. The Cumulus hub lists related historical project pages.

Sources