Today I noticed my cygwin shell is showing the wrong time. It is actually UTC time while it is supposed to be my local time. As soon as I unset the TZ variable it shows the local time.
Here are some commands which show the situation.
I am running windows 10. My windows has UTC-5:00 timezone and its time is OK.I do not remember when did it start to be like this but my colleagues computers are fine. Has anyone seen this before ?
$ date
Mon, Oct 31, 2016 9:13:38 PM
$ date --utc
Mon, Oct 31, 2016 9:13:42 PM
$ echo $TZ
America/Toronto
$ unset TZ
$ date
Mon, Oct 31, 2016 5:13:56 PM
$ cygcheck.exe -V
cygcheck (cygwin) 2.6.0
System Checker for Cygwin
Copyright (C) 1998 - 2016 Cygwin Authors
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
As you might already know, Cygwin sets the timezone in this file :
$ tail -1 /etc/profile.d/tzset.sh
test -z "$TZ" && export TZ=$(/usr/bin/tzset)
Thanks to matzeri that pointed out my tzdata, I tried to reinstall tzdata and saw an error about cygintl-8.dll. I searched for that package in Cygwin web site and fount it there:
libintl8-0.19.8.1-2 - libintl8: GNU Internationalization runtime library (installed binaries and support files)
reinstalled the package and problem is resolved.
Related
For the past few months I have successfully been using my Mac to connect to a Windows sstp VPN for work using homebrew....until now.
I followed the instructions here:
Windows SSTP VPN - connect from Mac
and use this command:
sudo /usr/local/sbin/sstpc --log-stderr --cert-warn --user <user> --password <password> <server> usepeerdns require-mschap-v2 noauth noipdefault defaultroute refuse-eap noccp
Now, out of nowhere, I get an error:
Mar 24 12:20:50 sstpc[5481]: Could not complete write of frame
Mar 24 12:20:50 sstpc[5481]: Could not forward packet to pppd
Mar 24 12:20:50 sstpc[5481]: Could not complete write of frame
Mar 24 12:20:50 sstpc[5481]: Could not forward packet to pppd
Mar 24 12:20:51 sstpc[5481]: Connection was aborted, Reason was not known
**Error: Connection was aborted, Reason was not known, (-1)
The numbers in the brackets sstpc[nnnn] vary, they're not always what is above.
I tried updating homebrew, reinstalling the sstp-client from homebrew, restarting my computer.
What else can I try?
There is a serious bug in sstp-client 1.0.14 which causes this [1], you likely need to downgrade to 1.0.13.
Unfortunately homebrew does not have tagged versions for sstp-client, so it is a little more involved - you will need to create a local tap so you can pin the version:
$ brew uninstall sstp-client
$ brew tap-new mymac/local
$ brew extract --version 1.0.13 sstp-client mymac/local
$ brew install mymac/local/sstp-client#1.0.13
Now it should work as before.
[1] https://sourceforge.net/p/sstp-client/discussion/1499218/thread/d485651bda/?limit=25#268f/038f/4b89/f7be/ffd5
My raspi knows when EDT (Eastern US Daylight Time) is active,
HypriotOS/armv7: pirate#black-pearl in ~
$ date
Thu Oct 17 10:27:27 EDT 2019
the docker container for homeassistant knows when EDT is active,
root#black-pearl:/# date
Thu Oct 17 10:28:54 EDT 2019
but I cannot manage to get homeassistant v.0.100.2 to reflect this.
I've used
time_zone: EST
which does display the correct time if I were NOT in daylight savings.
Here's what else Ive tried:
passing in the hosts time, which clearly works as evidenced by the docker containers console
-v /etc/localtime:/etc/localtime
-v /etc/timezone:/etc/timezone:ro
Leaving blank in the hopes that freegeoip will solve this for me.
Using time_zone: EDT instead of EST but it isn't recognized as a valid config.
Ultimately I'm not above lying to hass and telling it we're in America/Moncton (UTC - 4) and manually switching it back to EST (UTC - 5) the night before our transitions, but thats not really in the spirit of automation so I'd rather not.
Any help?
America/New_York
SOLVED
this worked. im a dingus. if i knew how to read and FOLLOW DIRECTIONS i would have read to use tz_database_name instead of its common abbreviation.
credit to reddits u/kb5zuy
Following the instructions from the uWSGI SPDY router docs I didn't have much luck.
I've tried it on a vagrant instance Linux precise64 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Under a virtual environment.
$ python --version
Python 2.7.9
Issuing following command that I derive from the manual does fire up a server:
$ uwsgi --master --https2 addr==0.0.0.0:8443,cert=/home/vagrant/server.crt,key=/home/vagrant/server.key,spdy=asdf --module werkzeug.testapp:test_app --thunder-lock --socket=/tmp/uwsgi.sock --shared-socket :8443 -H /vagrant/venv/
Note that I'm forwarding host 8422 to guest 8443.
The problem is that checking https://spdy.localhost:8442/ doesn't show any Werkzeug variables described in the manual (SPDY, SPDY.version). The UWSGI_ROUTER has value of "http" if that's of any significance.
$ openssl version
OpenSSL 1.0.1 14 Mar 2012
Werkzeug Version 0.10.4
uwsgi.version '2.0.10'
I've made sure tat python doesn't produce insecure platform warning.
The OpenSSL seems to be OK version according to the manual.
There are no warnings or meaningful info messages in the log.
It just doesn't use SPDY routing it seems.
What might be the cause of this?
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