The Leap Year Edge Case
Scheduling logic often breaks on edge cases related to month lengths. If a cron job is scheduled with `0 0 29 2 *` (Midnight on February 29th), the standard scheduler will literally only execute it once every four years. If you meant 'the last day of February', standard cron has no built-in operator for 'last day of the month'.
*(Note: Some advanced schedulers like Quartz support the `L` character to indicate the last day).*
Daylight Saving Time (DST) Disasters
DST transitions are the source of major scheduler bugs and data corruption:
1. **Spring Forward (The Lost Hour)**: During the spring transition, the clock typically skips from 1:59 AM straight to 3:00 AM. Any cron job scheduled during that 2:XX AM window (e.g., `30 2 * * *`) **may never execute**. The system clock simply steps over it.
2. **Fall Back (The Duplicate Hour)**: During the autumn transition, the clock repeats the hour from 1:00 AM to 2:00 AM. Any job scheduled in this window **will run twice**.
The Universal Mitigation Strategy
For mission-critical production servers, the golden rule of sysadmin architecture is to always configure server system clocks and application cron schedulers to run on **Coordinated Universal Time (UTC)**. UTC does not observe daylight saving shifts, guaranteeing that every minute occurs exactly once per day, forever.