I changed the time zone of my server (Ubuntu 12.04) to UTC via:
echo 'UTC' > /etc/timezone
dpkg-reconfigure --frontend noninteractive tzdata
When running date, I can see the time is now in UTC.
However, on /var/log/syslog, it still displays the time with the previous setup timezone and not UTC. Why ?
How to make it take effect on the whole system? Reboot?
Thanks.
To have the syslog daemon pick up the new time zone, use the command:
sudo service rsyslog restart
I found the name of the service to restart with:
ls /etc/init.d/*log*
In general you will have to restart every process on the system that you want to see the new timezone. If there’s only one or two, like syslog, that you care about, then you can restart them individually, but you’re probably better off rebooting and getting everything consistent.
To switch to UTC, simply execute sudo dpkg-reconfigure tzdata, scroll to the bottom of the Continents list and select Etc; in the second list, select UTC. If you prefer GMT instead of UTC, it's just above UTC in that list.
Related
I use docker container to run tomcat.
Now I want to modify system date to use date -s '2012-12-25', but can not have privilege. So I use
libfaketime to faketime,as below
$LD_PRELOAD=/usr/local/lib/faketime/libfaketime.so.1 FAKETIME="+1d"
but only effectively current session.
So what can I do to effective the system date in container? Thanks!!!
The Turkish government decided to stay at the EEST (GMT+3) timezone (daylight saving timezone) from now on; the timezone will be fixed to GMT+3 from now on in Turkey. Is there going to be an update for the timezone file for Linux systems due to this change? When is it going to be published?
As long as it has been decided to stay in current timezone, you can use GMT+3 until getting any update from Turkish officials.
sudo unlink /etc/localtime
sudo ln -s /usr/share/zoneinfo/Etc/GMT+3 /etc/localtime
Good luck!
Looks like for vmware no need to play on it , its default UTC
Related article
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2135594
Don't use +3 because zones like Etc/GMT+6 are intentionally reversed for backwards compatibility with POSIX standards.
Instead of +3 use below;
sudo unlink /etc/localtime
sudo ln -s /usr/share/zoneinfo/Etc/GMT-3 /etc/localtime
Otherwise you will have the reversed and will have 6 hours difference.
I'm a new user of GCE instances.
I created instances a week ago and changed timezone to Asia/Shanghai by commands below:
cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
Then yesterday, I found that my system timezone changed to UTC automatically and /etc/localtime was changed. So I run the command above agina. Until now it's OK.
After that I checked many resources and export TZ='Asia/Shanghai'. But I still not know if it's the root cause or not.
Also I find that someone adds xen.independent_wallclock=1 in sysctl.conf file to maintain independent times. But it's for Xen VM and I'm not sure if it's useful for GCE.
Could anyone please take a look at it ?
I've found a more user friendly approach here
Go root user
sudo -s
and use
dpkg-reconfigure tzdata
This will bring up a GUI which will guide you to change your timezone information
To make the permanent change edit $HOME/.profile or $HOME/.bash_profile appending the line and then log out and log in again:
TZ='Asia/Shanghai'; export TZ
for windows users open powershell as admin and type TZUtil.exe /s "<your new time zone>".
to see a list of all available time zones type TZUtil.exe /l.
for more info type TZUtil.exe /?.
I am running Jenkins on a Linux server and shows the wrong time :(
Situation:
I am running another java app (in tomcat that also runs Jenkins) that shows the correct time in the log files (I use Logback through slf4j).
The bios is set to the UTC time (system clock) like advises here: http://www.linuxsa.org.au/tips/time.html
In Linux it's indicated in /etc/sysconfig/clock that the system clock is set to UTC and in which timezone we are located. I am in UTC+1
Running date command on Linux shows the correct local time. Example:
Sun Jan 8 12:11:35 CET 2012
But Jenkins shows the time plus 1 hour :(...
The jenkins config shows:
user.timezone = Europe/Amsterdam (which is UTC+1).
I think that Jenkins (java) thinks the local clock is set to UTC such that 1 hour is added.
How do I solve this?
If you are running Jenkins with Docker, you can append -e JAVA_OPTS=-Duser.timezone=TZ to docker arguments.
docker run -e JAVA_OPTS=-Duser.timezone=$TZ jenkins
All available TZ can be found here.
See here: https://wiki.jenkins-ci.org/display/JENKINS/Change+time+zone
In short, you can set the system property, either modifying the JVM options,
java -Dorg.apache.commons.jelly.tags.fmt.timeZone=TZ ...
Or changing Jenkins configuration in /etc/default/jenkins (Debian) or /etc/sysconfig/jenkins (Red Hat):
JAVA_ARGS="-Dorg.apache.commons.jelly.tags.fmt.timeZone=America/New_York"
It also mentioned -Duser.timezone="..." is an option, but can cause problems / interfere with other contexts (some vague hand-waving & caveats: time travel is always unpredictable).
In general (in my experience), don't change the system time, since us, our servers & our data live in a global world & should be handling, sending, comparing all times in UTC until the latest possible moment: usually that's the GUI (presentation layer) just before being displayed (...if even then). (Our build system results actually produces data that is fed into another system in another time zone.)
On Jenkins 2.63 on Ubuntu 14.04.5 LTS setting
JAVA_ARGS="-Djava.awt.headless=true -Duser.timezone=America/Los_Angeles"
in /etc/default/jenkins and then doing
sudo service jenkins stop
sudo service jenkins start
worked for me to change the timezone from UTC to PDT.
Put this in a Dockerfile and it will work;
RUN echo "import hudson.model.*;" >
/var/jenkins_home/init.groovy.d/timezone.groovy && \
echo "import jenkins.model.*;" >>
/var/jenkins_home/init.groovy.d/timezone.groovy && \
echo "System.setProperty('org.apache.commons.jelly.tags.fmt.timeZone',
'America/Denver')" >> /var/jenkins_home/init.groovy.d/timezone.groovy
$JENKINS_HOME/init.groovy.d/*.groovy will get executed at start up.
System.setProperty('org.apache.commons.jelly.tags.fmt.timeZone',
'America/Denver')
That sets the timezone.
For official Jenkins Docker image (lts:2.138.1), you should set Jenkins java options to your local TZ. You can use this env. variable in a docker run command or docker-compose as well.
See here: https://wiki.jenkins.io/display/JENKINS/Change+time+zone
JENKINS_JAVA_OPTIONS="-Duser.timezone=Europe/Paris"
In case you have additional slaves you can sync the clock by using ntp. On Linux you can run following commands for each slave:
sudo systemctl stop ntp
sudo ntpdate -qu 0.debian.pool.ntp.org
sudo systemctl restart ntp
sudo systemctl status ntp
The easiest way without restarting Jenkins:
Open "Manage Jenkins" -> "Script Console"
Run the script:
System.setProperty('org.apache.commons.jelly.tags.fmt.timeZone', 'America/New_York')
I have no ideas how to fix this. In my /etc/TIMEZONE file the TZ variable has the correct value (Canada/Eastern) and still it's showing a -1 hour lag. Where else should I be looking?
You should check what your hardware clock is.
I would suggest doing this:
Set the UTC time correctly. i.e. (5 AM in the example):
$ date -u -s "05:00"
Thursday, April 29, 2010 05:00:00 AM UTC
Set the hardware clock accordingly (tod for SPARC and rtc for x86):
$ rtc -c (the '-c' argument sets the DST correctly)
Check the date again:
$ date
Thursday, April 29, 2010 02:00:11 AM ART
Regards,
Leandro.
Is your machine patched up-to-date? There were changes in DST handling for North America in 2007. On my Solaris 10 I have:
-bash-3.00$ ls -l /usr/share/lib/zoneinfo/Canada/Eastern
-rw-r--r-- 2 root bin 1252 Jul 14 2008 /usr/share/lib/zoneinfo/Canada/Eastern
-bash-3.00$ openssl md5 /usr/share/lib/zoneinfo/Canada/Eastern
MD5(/usr/share/lib/zoneinfo/Canada/Eastern)= 82980b1345aab5a97d90307edfefb6da
Do you use NTP to set the time automatically or do you do it manually?
Volker
When you actually log into the host, what timezone is set in your shell session?
If the timezone in your shell session doesn't match /etc/TIMEZONE, then you probably need to reboot for the timezone change to take effect.
If the timezone in your shell session is correct, but the actual time is wrong, then either the system clock is off or the timezone definition file is wrong somehow. You can run "date -u" to get the UTC time, which will help you figure out if the actual clock is wrong.
That is the correct file to edit. The only other step required is a reboot. The reason a reboot is required is that the init process reads the value of TZ when it is started, and all other processes inherit this value. As far as I know, there is no way to make the change effective without doing a full reboot.
Also, make sure /etc/TIMEZONE is symlinked to /etc/default/init. For example:
[root#server:/etc]ls -l /etc/ | grep TIMEZONE
lrwxrwxrwx 1 root root 14 Jul 7 2008 TIMEZONE -> ./default/init