• Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Minor Minor
    • core
    • None
    • Jenkins 2.203

      Our Jenkins instances are used by users in multiple time zones. It would be nice if the user was able to set his/her time zone in user preferences, and for times to then be displayed local to that user.

          [JENKINS-19887] Allow time zone to be set on a per user basis

          This is a near duplicate of JENKINS-1962 "Detect timezone from browser".

          Christian Höltje added a comment - This is a near duplicate of JENKINS-1962 "Detect timezone from browser".

          Just trying to merge everything into one issue for better visibility.

          Christian Höltje added a comment - Just trying to merge everything into one issue for better visibility.

          Tim Drury added a comment -

          While detecting the user's timezone from the browser would be optimal, an easier implementation of this would be to provide either a timezone or timezone offset in the user's "People" page, then simply apply that offset to all the times displayed.

          Tim Drury added a comment - While detecting the user's timezone from the browser would be optimal, an easier implementation of this would be to provide either a timezone or timezone offset in the user's "People" page, then simply apply that offset to all the times displayed.

          Another approach for this could be to deliver all dates in a default timezone and use momentjs or a similar library to convert the date time on the frontend side to either the browsers timezone (this could be the default) or to a manually selected one.

          This would be rather easy to implement and would not require any big changes in jenkins itself, just all places that deliver times must be wrapped in some markup, e.g. a class and some data-fields (e.g. data-datetime containing a rfc3339 timestamp)

          Patrick Brückner added a comment - Another approach for this could be to deliver all dates in a default timezone and use momentjs or a similar library to convert the date time on the frontend side to either the browsers timezone (this could be the default) or to a manually selected one. This would be rather easy to implement and would not require any big changes in jenkins itself, just all places that deliver times must be wrapped in some markup, e.g. a class and some data-fields (e.g. data-datetime containing a rfc3339 timestamp)

          Josh Soref added a comment -

          Note that momentjs will not work if the server already merges two date objects into some datedelta – https://github.com/jenkinsci/jenkins/pull/3525 will probably introduce a case where two dates are subtracted resulting in a number.

          Personally, I like the idea of using momentjs (or similar).

          Josh Soref added a comment - Note that momentjs will not work if the server already merges two date objects into some datedelta – https://github.com/jenkinsci/jenkins/pull/3525  will probably introduce a case where two dates are subtracted resulting in a number. Personally, I like the idea of using momentjs (or similar).

          Adam Gent added a comment -

          I briefly looked around and this would not be that hard to implement if only you could get the root JellyContext.

          Once you have the JellyContext then just you just intercept the calls:
          JellyContext.getVariable(Config.FMT_TIME_ZONE);

          Or set the variable since the context is mutable.

          The JellyContext is already bound to a request via a ThreadLocal in ExpressionFactory2 so you just need to setup the parent JellyContext to look at user config.

          The problem is that Stapler makes its own JellyContext called CustomJellyContext in DefaultScriptInvoker per request (which is good)!

          So in theory a custom DefaultScriptInvoker that pulls user configuration logic and sets the context with that user logic should be able to set the correct time zone variable.

           

           

          Adam Gent added a comment - I briefly looked around and this would not be that hard to implement if only you could get the root JellyContext. Once you have the JellyContext then just you just intercept the calls: JellyContext.getVariable(Config.FMT_TIME_ZONE); Or set the variable since the context is mutable. The JellyContext is already bound to a request via a ThreadLocal in ExpressionFactory2 so you just need to setup the parent JellyContext to look at user config. The problem is that Stapler makes its own JellyContext called CustomJellyContext in DefaultScriptInvoker per request (which is good)! So in theory a custom DefaultScriptInvoker that pulls user configuration logic and sets the context with that user logic should be able to set the correct time zone variable.    

          As a workaround, I added the below script to my tampermonkey extension in Chrome. This allows me to view the dates in a job in my computer's timezone. Might be of interest to some of you.

           

          // ==UserScript==
          // @name         Local Jenkins job dates
          // @namespace    http://tampermonkey.net/
          // @version      0.1
          // @description  use local date for Jenkins jobs
          // @author       You
          // @match        https://myjenkinsdomain.com/job/*
          // @grant        none
          // ==/UserScript==(function() {
              'use strict';    const allTimes = document.querySelectorAll('div[time]');
              allTimes.forEach(d => {d.textContent = new Date(+d.getAttribute('time')).toLocaleString('en-US', {day: "2-digit", month: "short", year: "numeric", hour: "numeric", minute: "numeric"});});
          })(); 

          Morgan Kobeissi added a comment - As a workaround, I added the below script to my tampermonkey extension in Chrome. This allows me to view the dates in a job in my computer's timezone. Might be of interest to some of you.   // ==UserScript== // @name Local Jenkins job dates // @namespace http://tampermonkey.net/ // @version 0.1 // @description use local date for Jenkins jobs // @author You // @match https://myjenkinsdomain.com/job/* // @grant none // ==/UserScript==(function() { 'use strict' ; const allTimes = document.querySelectorAll( 'div[time]' ); allTimes.forEach(d => {d.textContent = new Date(+d.getAttribute( 'time' )).toLocaleString( 'en-US' , {day: "2-digit" , month: " short " , year: "numeric" , hour: "numeric" , minute: "numeric" });}); })();

          Jon Hermansen added a comment -

          Thank you mcmoe for the userscript!

          Jon Hermansen added a comment - Thank you mcmoe for the userscript!

          Oleg Nenashev added a comment -

          The feature has been released in Jenkins 2.203. It has a good chance to appear in the next LTS

          Oleg Nenashev added a comment - The feature has been released in Jenkins 2.203. It has a good chance to appear in the next LTS

            Unassigned Unassigned
            brianegge Brian Egge
            Votes:
            74 Vote for this issue
            Watchers:
            54 Start watching this issue

              Created:
              Updated:
              Resolved: