Am 27.10.2014 um 16:49 schrieb James Nord:
If you set the timezone to Etc/UTC even on windows the hardware clock will
never jump - as there is no DST to adjust the clock by.
Yes, that's clear. But this time will also be displayed to the user,
which is not the nicest thing to have for most
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
It's not a big problem for us (it might be more of a problem for others), but
any suggestions as to how to handle this in future
My preffered way of handling this is to always run your infrastructure in
Etc/UTC.
It means you never hit the time changing issue - and when you need to integrate
Am 27.10.2014 um 11:23 schrieb James Nord (jnord):
My preffered way of handling this is to always run your infrastructure in
Etc/UTC.
Fine if it's Unix/Linux. Doesn't work on Windows, because hardware clock
is always on localtime there.
Bye...
Dirk
--
*Dirk Heinrichs*, Senior Systems
: jenkinsci-users@googlegroups.com
[mailto:jenkinsci-users@googlegroups.com] On Behalf Of Dirk Heinrichs
Sent: 27 October 2014 10:32
To: jenkinsci-users@googlegroups.com
Subject: Re: Jenkins problem with clocks going back?
Am 27.10.2014 um 11:23 schrieb James Nord (jnord):
My preffered way
Am 27.10.2014 um 11:47 schrieb James Nord (jnord):
I really don’t follow – unless you are on an out of date windows
verison it does now have an option for UTC as a proper UTC unline the
old “Grenwich Mean Time” which was actually Europe/London.
OK, I need to elaborate. On Unix/Linux, one
Hi Dirk,
If you set the timezone to Etc/UTC even on windows the hardware clock will
never jump - as there is no DST to adjust the clock by.
/James
--
You received this message because you are subscribed to the Google Groups
Jenkins Users group.
To unsubscribe from this group and stop
As the originator of this thread, thanks for your responses. We're on Linux, so
the Windows concerns thankfully don’t apply.
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
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
