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": {
    "input": "Every Sunday at 9am",
    "timezone": "America/New_York",
    "count": 20
  }
}

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 deduplicates rare recovery redeliveries.

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

Try in DashboardTesting Webhook Delivery