Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: blueocean-plugin
    • Labels:
      None
    • Environment:
      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
    • Sprint:
      pannonian
    • Similar Issues:

      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

          Hide
          michaelneale Michael Neale added a comment -

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

          Show
          michaelneale Michael Neale added a comment - So was the time totaly wrong or consistent with the 10 mins drift?
          Hide
          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

          Show
          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
          Hide
          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`

          Show
          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

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

              Dates

              • Created:
                Updated:
                Resolved: