Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-22106

@midnight is vulnerable to DST witching hours

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      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.

        Attachments

          Issue Links

            Activity

            Hide
            jglick 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.

            Show
            jglick 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.
            Hide
            mwebber 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.

            Show
            mwebber 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.
            Hide
            jglick Jesse Glick added a comment -
            Show
            jglick Jesse Glick added a comment - Matthew Webber that is JENKINS-19977 .

              People

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

                Dates

                Created:
                Updated:
                Resolved: