Recurrence Edge Cases

Basic recurrence is easy. Production recurrence is hard. rrule.net is battle-tested against DST boundaries, leap years, bounded rules, timezone shifts, and long-running schedules.

What breaks simple schedulers

  • Daylight Saving Time transitions (UTC offset changes)
  • Leap years and variable month lengths
  • Finite recurrences (COUNT / UNTIL)
  • Old high-frequency schedules resumed long after creation
  • Wall-clock invariants across timezones

Challenge scenarios

Pick a scenario, run it in your own scheduler, and compare behavior. All examples below are generated relative to the current date to avoid stale test data.

dst

Weekly at 09:00 America/New_York across DST

Wall-clock time should stay at 09:00 local while UTC timestamps shift at DST boundaries.

Input

{
  "endpoint": "POST /v1/schedules/simulate",
  "payload": {
    "rrule": {
      "dtstart": "2026-03-31T19:00:00.000Z",
      "rule": "FREQ=WEEKLY;BYDAY=SU;BYHOUR=9;BYMINUTE=0;BYSECOND=0"
    },
    "timezone": "America/New_York",
    "count": 6
  }
}

Expected behavior

{
  "expectation": "Occurrences stay on Sunday 09:00 local time, with UTC offsets changing when DST changes."
}

How to use this guide

  1. Use validate and simulate to confirm recurrence logic.
  2. Create a real schedule with a test endpoint (webhook.site or ntfy.sh).
  3. Verify execution history and payload shape.
  4. Ensure your consumer is idempotent for at-least-once delivery.

If your system passes these scenarios consistently, you are much closer to production-grade recurrence handling.

Try in DashboardTesting Webhook Delivery