A recurrence rule is a program, not a date
RRULE:FREQ=MONTHLY;BYDAY=-1FR;COUNT=12 does not contain a single date. It contains instructions for producing them, and the only honest way to answer when does this actually happen is to run those instructions. This tool runs them.
What is applied
Every part of RFC 5545 §3.3.10: FREQ, INTERVAL, COUNT, UNTIL, WKST, all nine BY* parts including negative ordinals such as -1FR ("the last Friday"), and BYSETPOS. On top of the rule, EXDATE removes dates and RDATE adds them — and each row says which of the two it came from, because a date that only exists because someone added it by hand is a different thing from one the rule generated.
Why the UTC offset column matters
A weekly 09:00 meeting stays at 09:00 when the clocks change. The instant moves by an hour; the wall-clock reading does not. That is what RFC 5545 requires, and it is what a naive "add 7 × 86 400 000 milliseconds" gets wrong twice a year. So every occurrence shows both readings side by side: the local time, and the real UTC instant with the offset that produced it. When two occurrences have different offsets the tool says so explicitly.
Zones are resolved from your browser's IANA database when the TZID is a real zone name, and from the VTIMEZONE block inside the file otherwise — which is how Microsoft's invented names like Romance Standard Time still resolve correctly. When neither works, the offset is shown as unknown rather than quietly assumed to be UTC.
Limits, stated plainly
An endless rule is expanded up to the cap you set and the result is marked as truncated. A rule with impossible constraints — FREQ=YEARLY;BYMONTH=2;BYMONTHDAY=30 is legal and can never match a real day — produces nothing, and the tool says why instead of showing an empty table.
Privacy
Everything runs in your browser. No calendar file is uploaded and nothing here contacts the network.
Tiny Online Tools







