On 27.10.2014, at 17:16, matthew.web...@diamond.ac.uk wrote: > As stated, the usual way to handle this kind of thing is for the server to > keep time in UTC, and the application converts to local time for display etc. > purposes. The application, in this case, is Jenkins, and it doesn't look like > it really handles this properly - it does everything in local time, and gets > confused with the summer time change.
There are two pull requests that may help here: https://github.com/jenkinsci/jenkins/pull/1376 https://github.com/jenkinsci/jenkins/pull/1379 ---- Regarding configuration options: https://wiki.jenkins-ci.org/display/JENKINS/Change+time+zone The Jelly date format property only applies to the UI, so it seems straightforward to run Jenkins on UTC (incl. build IDs) and display local time on the UI. I'm currently trying to run a test instance with the following: -Duser.timezone=Universal -Dorg.apache.commons.jelly.tags.fmt.timeZone=Europe/Berlin So far it seems to behave correctly (Server is in CET, Build IDs are in UTC, and the UI -- except things like timer triggers -- is in CET again). ---- FWIW I had the problem where builds were scheduled to run hourly, and the 2:xx AM CET builds appear to have overridden the 2:xx AM CEST builds with identical ID, resulting in a SEVERE log message when they were supposed to be log rotated ("Failed to rotate log"). For me, deleting the obsolete build symlink did the trick. No idea how to handle if the builds aren't auto deleted. I'd be extra careful with builds created during those two hours. -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
