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

Time reported is not correct

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Minor
    • Resolution: Fixed
    • blueocean-plugin
    • None
    • Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux
      Jenkins v2.33
      BlueOcean v1.0.0-b14
    • pannonian

    Description

      When watching a job which is currently running, a chrono display the time spent since the job started on the upper right corner. It seems that this chrono mixes timestamp from the server hosting jenkins and from the client displaying the page.

      For example my client didn't use network based date time, and was 10 minutes ahead of the server, which meant that the time displayed was 10 minutes more than expected.

      Attachments

        Activity

          Ascending order - Click to sort in descending order
          michaelneale Michael Neale added a comment -

          So was the time totaly wrong or consistent with the 10 mins drift?

          michaelneale Michael Neale added a comment - So was the time totaly wrong or consistent with the 10 mins drift?
          xgouchet Xavier Gouchet added a comment -

          The time was always consistent with the 10 minute drift.

          Also after synchronizing the clock on both computers (server and client) with ntp, the time reported was always correct

          xgouchet Xavier Gouchet added a comment - The time was always consistent with the 10 minute drift. Also after synchronizing the clock on both computers (server and client) with ntp, the time reported was always correct
          tscherler Thorsten Scherler added a comment -

          Hmm, that is a tricky one.

          We use the server timestamp indeed for both times in the header.

          const durationMillis = run.isRunning() ?
moment().diff(moment(run.startTime)) : run.durationInMillis;
...
<ReadableDate
  date={run.endTime}
  liveUpdate
  locale={locale}
  shortFormat={t('common.date.readable.short', { defaultValue: 'MMM DD h:mma Z' })}
  longFormat={t('common.date.readable.long', { defaultValue: 'MMM DD YYYY h:mma Z' })}
/>

          I think I have to read the http response header to see when the server answers and then compare that with local time. In case they are different I need to adopt the above `startTime` and `endTime`

          tscherler Thorsten Scherler added a comment - Hmm, that is a tricky one. We use the server timestamp indeed for both times in the header. const durationMillis = run.isRunning() ? moment().diff(moment(run.startTime)) : run.durationInMillis; ... <ReadableDate date={run.endTime} liveUpdate locale={locale} shortFormat={t( 'common.date.readable. short ' , { defaultValue: 'MMM DD h:mma Z' })} longFormat={t( 'common.date.readable. long ' , { defaultValue: 'MMM DD YYYY h:mma Z' })} /> I think I have to read the http response header to see when the server answers and then compare that with local time. In case they are different I need to adopt the above `startTime` and `endTime`

          People

            tscherler Thorsten Scherler
            xgouchet Xavier Gouchet
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: