When I look at the log files for my application, the entries are listed in UTC. However, I want the entries to reflect my local timezone. Can you customize the time zone for the log files?
I did not find the information in the documentation. I used the following commands to change the time zone to US Eastern time:
cf set-env <app-name> JAVA_OPTS '-Duser.timezone=America/New_York'
cf restage <app-name>
As an alternative, I could have changed the manifest.yml file.
Related
I have an issue with timestamp on rundeck, my machine hosting the application is in Europe/Paris timezone and CEST time but in Rundeck the timestamp displays in UTC.
So all the jobs are two hours late...
After reading many posts about this topic, tried to add this option in the profile configuration file but without success:
RDECK_JVM_OPTS="-Duser.timezone=Europe/Paris"
Have you ever had this issue? Can you please help me?
Thanks, BR.
Stop the Rundeck service.
If you're using a Debian/Ubuntu-based instance create the /etc/default/rundeckd file. If you're using a Redhat/CentOS/Rocky-based instance create the /etc/sysconfig/rundeckd file.
The rundeckd file must contain the following content:
RDECK_JVM_OPTS="-Duser.timezone=Europe/Paris"
Save the file and then, Start the Rundeck instance.
You can test on two different timezones: Paris and Santiago (America/Santiago).
I am trying to change Date and time settings to UTC+10 Canberra,Sydney,Melbourne on the instance but it always keep rolling back to UTC+00 Monrovio, Reykjavik. Doesn't matter even if I select set time zone to automatic.enter image description here
The zone "australia-southeast1-b" on the provided screenshot is a deployment area for Google Cloud Platform resources, where the physical hosts, your VM instance is running on, are physically located. This is a geographical zone. It is not relevant to time.
To configure Date and Time in Windows, you should:
set correct time zone in Windows and
make sure a time server is reachable
Google Cloud Engine VM instance is just a virtual machine that boots up with hardware clock set to UTC as many modern servers do nowadays.
If you looked at the VM instance logs in the GCP Console you'd see that VM BIOS reports time in UTC
2019/10/3 14:9:44 Begin firmware boot time
After a while BIOS hands over to the bootloader
2019/10/3 14:9:45 End firmware boot time
Booting from Hard Disk 0...
The OS boots up. Behind the scene the OS time service recognizes the system timezone, then sets up and synchronizes time with the time source. From that time forward running programs and services report events based on the local system time:
...
2019/10/03 09:10:05 GCEWindowsAgent: GCE Agent Started (version 4.6.0#1)
In the Windows Event Log you should see entries made by the Time-Service:
Log Name: System
Source: Time-Service
Level: Information
The time provider NtpClient is currently receiving valid time data from metadata.google.internal,0x1 (ntp.m|0x1|0.0.0.0:123->169.254.169.254:123).
The time service is now synchronizing the system time with the time source metadata.google.internal,0x1 (ntp.m|0x1|0.0.0.0:123->169.254.169.254:123).
In the command prompt you can ensure that the time configuration and state are correct:
C:\Users\user>systeminfo | find /i "Time"
System Boot Time: 10/3/2019, 9:09:49 AM
Time Zone: (UTC-06:00) Central Time (US & Canada)
Hence you don't need synchronizing time neither manually or with any startup script. The time service will do this for you: synchronize the system time shortly after the system boot and keep it in sync afterwards.
All you need is to set correct Time zone and the Internet time server for Windows, and then make sure the time server is reachable via the network.
If you can't wait for the timesync cycle completion, you can logon to Windows and force time synchronization manually:
net stop W32Time
net start W32Time
w32tm /resync /force
To O.P
Answer to your question if I understand correctly, your answer is:
timedatectl set-timezone "Australia/Melbourne"
I have a dev environment and a production environment. The time() function returns the correct timestamp in my dev env but in my production environment time() is exactly 59 seconds behind!
The version of PHP is 7.0.3 on both environments.
This can't be a timezone issue since the difference is only one minute and the PHP default timezone is the same in both environments (America/Los Angeles).
It is now 10:48:29 am and here is the output from calling this function simultaneously in both environments (or at least as fast as I can press enter on the console).
Dev environment (is correct)
php > echo date('h:i:s A');
10:48:29 AM
Production environment (is one minute behind)
echo date('h:i:s A');
10:47:31 AM
Same happens with the time() function
Dev environment (is correct)
php > echo time();
1568742851
Production environment (is one minute behind)
echo time();
1568742792
And 1568742851 - 1568742792 = 59 secs
I know i could just add 59 seconds to the timestamp time() returns but that just seems like a hack and does not solve the problem. I would like to please get advice as to how to fix my production environment.
Confirm that you are allowing NTP traffic to your production OS environment. You can confirm that your server is properly communicating to NTP by running the following command ntpq -c peers If you receive a Connection refused prompt you don't have proper connectivity. You will need to configure an inbound firewall rule allowing UDP traffic on port 123. Once this is done, restart your NTP service service ntpd restart and rerun the ntpq -c peers command
I believe the system clock on your production and dev machine is unsync, Regardless of the version of PHP or Operating System, Just like #g_bor mentioned in comment.
Don't get confused by the time zone, Just run the command date +%s on system shell to print timestamp on both machines, If you have no permission (can't login with ssh), You can prepare the PHP file which contains system('date +%s');, And then, Upload to your web server and open the browser to check the timestamps on both your machines.
I have an MSDOS 6.22 application which uses NFS to access files on a Unix server. It shows file dates 20 days older than the actual file date on the server. A DIR command shows the same incorrect date. A Wireshark trace shows that the Unix server does pass the file modification date correctly as seconds since 1970 in the ‘mtime’ field. Why does the date appear wrong to the DOS applications?
Check for the presence of a TZ environment variable, and if used, run a test without TZ. The MSDOS Borland / Turbo C library function unixtodos() uses the TZ variable, but performs no validity checks. So a TZ value of GMT+0500 or GHO+0500 for example (from a Ghost installation) will cause a date shift of many days.
I have a Python application running as a Cloud Foundry app.
The timezone for the entire container/vm for my application is UTC, even though it is deployed in the US south region.
It's not just that messages in the log files are from the future, but some parts of the application rely on the current time. I tried to change the time zone via SSH from the application's management page but of course I do not have permissions.
I notice something similar on DSX.
Questions:
How do I change the time zone for the application and the container/vm it is running in?
Shouldn't the timezone be set to whatever region it is deployed in?