Content Calendar with Recurring Posts

An editorial calendar is an old tool with a plain purpose. Publishers, bloggers and businesses use one to control when content appears across a newspaper, a newsletter, a blog and social accounts, so that readers find something regular and nobody is surprised by a gap. For a small team the calendar does something less obvious: it turns good intentions into promises that can be checked.

A wish to post more often stays a wish until it has a date. Once it has one, it can collide with other dates. Two articles on consecutive mornings compete for the same readers. A podcast episode lands on the day of the offsite. A newsletter goes quiet for five weeks because the person who writes it took a holiday that was in their own calendar and nowhere else. None of these are failures of writing. They are failures of arithmetic, and arithmetic is the part a calendar can do well.

Cadence is a series, not a list of dates

Most of what a small team publishes repeats. The weekly tip goes out on Tuesday and Thursday. The newsletter leaves on the first Monday of the month. The recap appears on the last working day. Writing each of these as separate entries is how plans drift: one is moved, the next is forgotten, and the pattern that readers relied on dissolves without anyone deciding it should.

Treating a repeating post as a series keeps the decision in one place. Change the rule and every future date follows; move one date and only that date moves. The calendar standard has words for exactly this. A recurring event carries a rule, a list of extra dates, and a list of exception dates that are removed from what the rule produces. A single changed occurrence is written as a separate entry that points back to the original date it replaces. That separation matters, because “move this one” and “change all of them” are different instructions, and a plan that cannot tell them apart will eventually do the wrong one.

Spacing is the other half of cadence. Most teams carry rules they have never written down: no two blog posts within two days, no more than one newsletter a week, never ten quiet days in a row. Written down, these become checks. Measured start to start, in real elapsed time, they also survive clock changes; a gap of 47 hours across the autumn change is still 47 hours.

How a repeat rule actually works

The iCalendar standard, published as RFC 5545 in 2009 when it replaced RFC 2445, defines a small language for repetition. A rule names a frequency (daily, weekly, monthly, yearly and finer), an interval, and optional parts that pick days: by weekday, with an ordinal such as first or last; by day of the month, counted from the start or the end; by month; by week number; by day of the year.

A final part, the set position, picks from whatever the others produced in each period. “The last working day of the month” is a monthly rule over Monday to Friday with a set position of minus one. A rule ends after a count, on an inclusive last date, or never.

The standard is careful about order. It says the parts are applied month first, then week number, year day, month day, weekday, the time parts, and set position last, with count and end date checked after that. Some parts narrow the set and others widen it, depending on the frequency, and the standard prints a table of which does which. It also says the first date of the event is always the first occurrence, which is why the rule and the start date should agree.

Two corners of this language catch almost everyone. The first is the 31st. A rule for the 31st of every month does not mean the last day of every month. The standard is explicit that a rule which produces an invalid date, such as February 30, must ignore it and must not count it.

Planning a roundup “on the 31st” from October 2026 gives 31 October and 31 December, and nothing in November. A tool that quietly moves the November post to the 30th has invented a date the rule never asked for, and a calendar program that follows the standard will disagree with it. If the last day of the month is what you mean, the rule says so with a month day of minus one.

The second corner is the clock. Repeat rules work in local wall time: the post is at nine in the morning, whatever the offset from UTC happens to be that day. The standard recommends a start date tied to a named time zone precisely so that every occurrence keeps its local time across changes.

That leaves two awkward hours a year. When clocks go forward, some local times do not exist; when they go back, some happen twice. The standard settles both. A time that occurs twice means the first one. A time that does not occur is read with the offset in force before the gap, so it lands later by the size of the change. An erratum the RFC Editor has verified confirms that repeat rules follow the same reading rather than skipping such dates, which is also what major calendar programs do.

A worked example you can reproduce

Take a weekly digest set for 01:30 every Sunday in New York, starting on 4 October 2026. Most of the United States has kept daylight saving time from the second Sunday in March to the first Sunday in November since 2007, so the clocks go back on 1 November 2026. On that morning 01:30 happens twice, first at UTC minus four and then at UTC minus five. The rule keeps the wall time, the standard picks the first of the two, and the occurrence is at 05:30 UTC. A week later, on 8 November, 01:30 happens once, at 06:30 UTC. Seen from UTC, the post moved by an hour; seen from New York, it never moved at all.

Nothing in that example is exotic. It is one ordinary post on one ordinary Sunday, and a planner that stores each date as a fixed UTC offset gets it wrong by an hour.

Now move the same series to 02:30 and look at 14 March 2027, the second Sunday of that March. At 02:00 the clocks jump to 03:00, so 02:30 does not exist. The standard’s answer is 03:30 local time, the instant that 02:30 would have been under the old offset. Load the example plan in this tool with the time zone set to America/New_York and the weekend digest shows the first case flagged on 1 November. Start a series on 7 March 2027 at 02:30 and its list of next dates shows the second.

These answers come from the IANA time zone database, the public-domain record of every zone’s history that sits behind most operating systems and browsers. A browser exposes it through the time zone option of Intl.DateTimeFormat, which accepts names such as America/New_York and can split any instant into the local year, month, day, hour, minute and second. Python reads the same database through its zoneinfo module, where a fold of zero selects the earlier of two repeated times. Agreeing with both on every case is a reasonable test of a planner, and the checks behind this page compare against them.

Weeks need the same care. “No more than two posts a week” depends on where a week starts. ISO 8601 starts weeks on Monday and numbers them so that week one holds the year’s first Thursday, which gives every year 52 or 53 weeks. A planner that counts weeks some other way will flag different posts, and nobody will know why.

Planning around what is already there

A content plan does not live alone. The team already has meetings, offsites, school holidays and launches somewhere else, usually in a calendar program. Reading that calendar on the device, rather than retyping it, is what makes clash checks honest. The file format carries enough to do it properly: each event’s start, its end or duration, its repeat rule with exceptions and extra dates, and either a time zone name or a full description of the zone’s rules embedded in the file. Events marked as free time are listed but do not block anything.

What the plan gives back is a file of the same kind. A good one is boring in the right ways. Every entry has a unique identifier and a timestamp. Text escapes its commas, semicolons and backslashes. Long lines are folded so that none passes 75 octets, which in practice means counting bytes rather than letters, because a character outside plain ASCII takes several octets in UTF-8 and a fold must never split one. Line ends are a carriage return followed by a line feed. A spreadsheet export follows the comma-separated rules of RFC 4180: quotes around any field that holds a comma, a quote or a line break, and quotes inside doubled.

There is one export choice worth understanding. Writing times in UTC sounds safer, but a repeating rule written in UTC drifts an hour against local time at every clock change. If a calendar has to be written in UTC, the honest form lists each date rather than a rule.

What a planner cannot do

A calendar checks the promises you write into it. It cannot tell you whether a post is any good, when your readers are awake, or how a platform will treat what you publish. The spacing limits are yours; there is no standard posting frequency, and any number that claims to be one is advice dressed as fact.

It also depends on the time zone data in the browser. Governments change their rules, sometimes at short notice, and an older browser may not know yet. A file from another program can name a zone that cannot be identified, and then the only honest move is to read its times as local and say so. Within those limits, exact repeat rules and a clean file are the difference between a plan that holds and one that looks right until November.