rule→ics

Recurring Date Generator

A repeat rule expanded into real dates, and exported as a calendar file.

By opening this website or using its tools, you agree to our Terms and Privacy Policy.

On these days

Nothing selected, so the rule repeats on whatever weekday the first occurrence falls on.

Off produces all-day entries, which land on the same date for everyone regardless of time zone.

Set a first occurrence date to generate the series.

Network activity during processing
0 bytes uploaded

Your file never leaves your browser during processing

How it works

To generate a series of recurring dates, set a first occurrence and a repeat rule above — every date the rule produces is listed, and the whole series can be downloaded as a single .ics calendar file or copied as plain text.

A repeat rule is compact but opaque: "the last Friday of every second month until December" is easy to write and hard to picture. This page expands the rule into the actual dates so you can check them before they land in a calendar, a rota, or an invoice schedule. For a single event, the .ics event generator is the simpler tool.

Expansion follows RFC 5545, the standard that calendar applications use, rather than a friendlier interpretation. The visible consequence is that impossible dates are skipped rather than nudged: a monthly series on the 31st produces nothing in February, April, June, September, or November, and a yearly series on 29 February only occurs in leap years. That is what your calendar app will do with the same rule, so matching it is the point — but it surprises people, so the tool reports every period it skipped instead of leaving gaps for you to notice.

The .ics export writes each occurrence as its own event rather than one event carrying a repeat rule. That is deliberate. A rule-based recurring event has to be anchored to a named time zone to keep its local start time across a daylight saving change, which requires the file to carry a full definition of that zone’s rules — and a hand-built one is a guess importers mishandle. Converting each occurrence separately gets every one of them right, at the cost of a larger file. The standard `RRULE` string is still shown, because that is what you paste into a system that already knows your zone.

Series are capped at 500 dates, which is well past the point where a list stops being useful. If a series has to avoid weekends and public holidays, step through working days to see where a date should move.

Background reading: RRULE in plain English; How to create an .ics file, and what is inside one.

FAQ

How do I generate a list of recurring dates?

Set the first occurrence, choose daily, weekly, monthly, or yearly, set the interval, and say when it ends. The dates appear immediately and can be copied or downloaded.

Why did my monthly series skip February?

Because the day number does not exist in that month. A series on the 31st runs only in months that have one, which is how RFC 5545 and every calendar application expand the rule. The skipped months are listed so nothing is silent.

What is the difference between "same day number" and "same weekday position"?

The first repeats on the 15th of every month. The second repeats on, say, the third Tuesday, whatever date that falls on. Dates in the last seven days of a month are treated as "last", so a series on the 29th of a month starting in a 31-day month becomes "the last of that weekday".

What is an RRULE?

The standard text form of a repeat rule, defined by RFC 5545 — for example FREQ=MONTHLY;BYDAY=3TU;COUNT=12. It is what you paste into a calendar system or API that expands rules itself.

Why does the .ics file list every date instead of using the rule?

So the series keeps its local start time across daylight saving changes. A rule-based event would need an embedded time zone definition to do that correctly; converting each occurrence individually needs none and cannot drift.

Related tools