For servers using local time in regions with daylight saving time, twice a year there are "witching hours" for cron-like scheduling: a task scheduled for between 2:00 (AM, inclusive) and 3:00 (exclusive) will skip a day in the spring, and run twice on a single day in the fall. Unfortunately the @midnight macro in Jenkins is defined as H H(0-2) * * *, which for ⅓ of jobs will trigger the DST problem.
Perhaps it should be redefined as H H(0-1) * * * to avoid this? During upgrade this would cause a one-time occasion when some jobs run 23 hours after the last run, which is not great but probably not a big deal. And it compresses the "midnight" range unnecessarily for servers using (say) UTC.
- is related to
-
JENKINS-19977 Build records get confused by timezone changes
-
- Resolved
-
Correction: in the US, ⅓ of jobs would experience only the skipped run in the spring; another ⅓ would experience only the doubled run in the fall (for jobs for which H(0-2) resolves to 1). So only compressing the macro all the way to H 0 * * * would work in the US, and this might result in unacceptably high server load at night. Furthermore, variant policies in other countries (such as in Europe) might require different changes.
It seems that the only safe course of action for a Jenkins administrator is to set the server to use UTC. Ideally any times displayed by the system would still use the timezone requested by the browser, but the REST API and crontab form input would use UTC.