• Icon: Bug Bug
    • Resolution: Won't Fix
    • Icon: Minor Minor
    • core

      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.

          [JENKINS-22106] @midnight is vulnerable to DST witching hours

          Jesse Glick added a comment -

          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.

          Jesse Glick added a comment - 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.

          Another example of problems with the change from summer time:

          This morning, checking the "Manage Jenkins" page, it said:

          "Some projects have builds whose timestamps are inconsistent. These will confuse Jenkins when it tries to look up build records."
          There is a link to http://jenkins-ci.org/issue/18289.

          What happened is that the clocks went back (end of summer time), which means jobs scheduled in the "duplicated" hour run twice, and some of the later runs were at an earlier wall-clock time than the previous run. Hence Jenkins gets confused.

          Matthew Webber added a comment - Another example of problems with the change from summer time: This morning, checking the "Manage Jenkins" page, it said: "Some projects have builds whose timestamps are inconsistent. These will confuse Jenkins when it tries to look up build records." There is a link to http://jenkins-ci.org/issue/18289 . What happened is that the clocks went back (end of summer time), which means jobs scheduled in the "duplicated" hour run twice, and some of the later runs were at an earlier wall-clock time than the previous run. Hence Jenkins gets confused.

          Jesse Glick added a comment -

          Jesse Glick added a comment - mwebber that is JENKINS-19977 .

            Unassigned Unassigned
            jglick Jesse Glick
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: