So, the system time on my Ubuntu server updated appropriately with DST on Sunday.
However, the timestamp on my glassfish logs are still an hour off. I've restarted the application server, but this doesn't seem to have changed anything.
A quick hello-world indicates that the JVM grabs the (correct) system time. Any ideas on why
the time in the glassfish logs do not match the system or JVM date and time?
As suggested, I've also run the tzupdate tool. This does not seem to have done much.
Any ideas what's going on? How can I repair this?
You might need to update the JVM to get the latest time zone information. Or use the Timezone Updater Tool.
Related
Recently I came across this situation where I have two different types of logs in the server. One is directly using the JDK system time and displaying it another one is using log4j in WLP.
The one which is using log4j is logging time one hour early than the current system time in Austin machines as compared to Asia machines (Assuming time zone issue) (the log without log4j implementation is showing the correct time).
The situation may have occurred due to Day Light Saving. I looked into the log4j2.xml for its tag implementation and found something as follows
current pattern
**<pattern>%d{ISO8601} [%-50.50t] %marker [%p] %F:%L %C.%M() %n......MDC: %X %n......NDC: %x %n......MSG: %-70.70m %n</pattern>**
I tried to change it to the format
**<pattern>%d{yyyy-MM-dd}-%t-%x-%-5p-%-10c:%m%n</pattern>**
to see if it works.
And voila! It started logging the correct time.
[But the situation of restart are different, once completed restarted the machine & once just restarted the WLP, Just after restarting the WLP we found the log time stamp is almost similar to machine time stamp.]
However, I think ISO8601 format is more appropriate to keep.
Have you guys came across such situation or know some solution to it except the one which I tried.
The Time zone information of the server
Clock : UTC
Time Zone : America/Chicago
log4j Version used : log4j-2.x
So, again if you know any solution where daylight saving time can be automatically processed and display the right time with sync. to the current system time or is there any fix available in the latest log4j versions if any, please inform
Thanks
Is there a way to identify the JVM's default time zone without running a Java program on it? Are there any commands available using which I can take a look at it?
Yeah we all know what jvm is , but maybe author want to know what is a default timzeone of running jvm without restarting it and deploying code on it.
In such case you could maybe check command line of java process for properties (user.timezone) or connect to jvm via some tool like visual vm and check this property, I am not sure if there is some other way to do that.
If you have remote debugging enabled then it should be easier as you can connect via your favourite ide/tool and just evaluate default timezone.
My application deployed in a Debian vps in US, Los Angeles. So code like new SimpleDateFormat("yyyy-MM-dd HH:mm").format(new Date()) will return current time of America/Los Angeles.
Can I do some setting in Tomcat's configuration file (server.xml or catalina.sh or what?) so that get current time will return a specified TimeZone like GMT+8 or Asia/Taipei ???
With all of the different places where you can set timezones, it's (in general) always best to explicitly set the timezone when you're dealing with times. Yes, your server is in Los Angeles, but where are your users?
As explicitly dealing with timezones makes your application somewhat more complex (but also more correct, less surprising, harder to test) the next best would be to explicitly make tomcat (java) know what timezone your server clock is set to. Careful: There are some levels to set this: Set your server clock to UTC, configure your server OS to be PST and then let java know of the timezone that your server is on, e.g. in setenv.sh do CATALINA_OPTS="$CATALINA_OPTS -Duser.timezone=America/Los_Angeles" (or whatever your timezone is) to configure Java for your timezone.
Test, rinse, repeat until happy with the configuration. But make it an explicit choice on all different levels that you can set your hands on. Resolving the timezone is rather a java than a tomcat feature.
It's quite important for maintainability of your software to always store times in UTC. If you ever store in your local timezone, calculating any other timezone will be a mess - think daylight savings times, change of timezones of different areas of the world etc.
So: Set your server to UTC, then get the current time, check if it's correct. For display purposes, you might use the (user's) local timezone (e.g. PST), but for storage and calculation, UTC is highly recommended.
Tomcat's personal timezone would be specified in its startup script in a form like:
-Duser.timezone=GMT
In the Linux just add the following line in setenv.sh which is at CATALINA_HOME/bin/.
CATALINA_OPTS="-Duser.timezone=Asia/{your zone}"
For Windows - Go to catalina.bat and add CATALINA_OPTS property(under start).
:doStart
shift
set CATALINA_OPTS=-Duser.timezone=America/Denver
If you want to change it from eclipse... Run --> Run configuration --> Apache tomcat --> Tomcat Server --> VM arguments add -Duser.timezone=America/Montreal
I have a java app which runs on a linux/unix machine.
When setting the system time via system command, on the console using date I see that the date/time has changed, but it seems as my JVM didn't recognize this change.
It seems that this is not a rights problem, because in the shell I see that the date/time has changed. Only my JVM didn't recognize this change.
Any hints where to search ?
Take a look at this post over on the super user stack exchange. There are 2 different clocks in linux. One is hardware (hwclock) and the other is os/system.
In my client, I have this code:
System.out.println("Java tz: " + TimeZone.getDefault());
System.out.println("Joda tz: " + ISOChronology.getInstance());
These two lines run one after another. I never set time zone or user.timezone manually, just rely on defaults read from the OS & local system.
When executed, they produce:
Java tz: sun.util.calendar.ZoneInfo[id="UTC",offset=0,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]
Joda tz: ISOChronology[America/Phoenix]
System time zone is indeed Phoenix, not UTC. How can Joda be correct and JDK be wrong?
EDIT: This is a Windows 7 x64 host, JRE is 1.6.22 x64.
EDIT 2: Don't try to reproduce it. It only fails on some, not all systems (like a few dozen in our 3k user base). I already know Joda checks user.timezone and then TimeZone.getDefault(). So I am looking for an explanation on how can it be different between me calling TimeZone directly and Joda doing it by itself.
When you say "defaults read from the OS & local system", there isn't a single, well-defined place to read this default from. Even the API documentation itself says
Gets the default TimeZone for this host. The source of the default TimeZone may vary with implementation.
So the simple answer is that Joda and your JVM are inferring the default time zone from different sources of information. The point to remember about this is that the default is a guess, not something that the JVM can definitively get access to.
For Sun's 1.5.0_06 JVM on Linux, the following order is used:
Looks to environment variable TZ
Looks for the file /etc/sysconfig/clock and tries to find the "ZONE" entry.
Compares contents fo /etc/localtime with the contents of every file in /usr/share/zoneinfo recursively. When the contents matches, it returns the path and filename, referenced from /usr/share/zoneinfo.
Joda 1.6.2 uses:
The system property user.timezone.
If the above is null or not a valid identifier, the value of the JDK's TimeZone default is used.
If that fails, UTC is used.
So if you have the above versions of JDK and Joda, I suggest that the user.timezone property may be set in your environment. Other versions may will use other algorithms to acquire the default, though.
Edit: In Sun's JDK 1.6.0_22, the default search first inspects the user.timezone property as well, and if that isn't found it looks up the user.country property in order to get the default value for a country. If neither is set, the default of GMT is used. So the results you observe may well change with your JVM version.
Edit 2: If you've got the source to both (and indeed the sources are both available), then you can simply trace it! Step through the Joda call, to see if it does indeed defer to java.util.TimeZone.getDefault(), and see what the returned value is. Then invoke the JDK method directly and see what you get.
Looking at the JDK sources, it seems that the default timezone is accessed via an inheritable thread local. Thus if someone somewhere calls TimeZone.setDefault(), it may or may not be visible in other threads, depending on whether they've looked up the version already. If you're getting apparently anomalous results from debugging the calls, it could well be simply due to the fact that different threads can have different default TimeZones.