0

We have one of our application hosted on a application server installed on machine working in CST timings. Now in the application footer we are showing the Last Login time and date using java.util.date().toString();

Now from reference of this post I can say java.util.Date().toString() is using TimeZone.getDefault() method which, in turn, will default to the time zone of the operating system it is running on (i.e. the host).

So the application Should show the timings according to CST timzone but it is not happening only for this server, it is always showing GMT timzone.

Here is a attached screenshot showing time configuration and the results from ‘time’ command on the serve, as well as the application Admin UI, showing time in GMT which is visible in footer.

So I am looking for the possible causes as why java.util.date.toString() is showing this unexpected behavior and what is the solution for that?

enter image description here

halfer
  • 19,824
  • 17
  • 99
  • 186
Nikhil Agrawal
  • 26,128
  • 21
  • 90
  • 126

3 Answers3

2

As you have already recognized, the behaviour of java.util.Date.toString() is based on TimeZone.getDefault().

  • Use the user.timezone property value as the default time zone ID if it's available.
  • Detect the platform time zone ID. The source of the platform time zone and ID mapping may vary with implementation.
  • Use GMT as the last resort if the given or detected time zone ID is unknown.

The JVM might not be able to interprete the timezone of the underlying operating system, for example if the OS uses Windows timezone names which cannot be resolved to identifiers common in iana-tzdb.

Solution:

I suggest you to start the JVM with following system property:

-Duser.timezone=America/Chicago
Meno Hochschild
  • 42,708
  • 7
  • 104
  • 126
1

Better use Joda-Time, a date-time object (DateTime) truly does know its assigned time zone. That means an offset from UTC and the rules and history of that time zone’s Daylight Saving Time (DST) and other such anomalies.

The standard date and time classes prior to Java SE 8 are poor. By tackling this problem head-on, Joda-Time became the de facto standard date and time library for Java prior to Java SE 8. 

DateTimeZone dateTimeZone =     DateTimeZone.forID("America/Chicago");
DateTime dateTime = DateTime.now(dateTimeZone);
System.out.println("Current time is: " + dateTime);

References: Joda Time: http://googleweblight.com/?lite_url=http://www.joda.org/joda-time/&ei=fiQH2-Y-&lc=en-IN&s=1&m=717&host=www.google.co.in&ts=1456818933&sig=ALL1Aj74vOgr-H7yxBKCAWq5KKQ28MTvvw

Time zones: http://joda-time.sourceforge.net/timezones.html

Aajan
  • 927
  • 1
  • 10
  • 23
  • 1
    The project is in maintenance mode!!! I can't make bigger changes as they can disturbed other functionalities just I want to know what can be the possible causes for showing abnormal behavior!! – Nikhil Agrawal Mar 01 '16 at 09:04
  • The date.toString method logic is TimeZone zi = date.getZone(); if (zi != null) { sb.append(zi.getDisplayName(date.isDaylightTime(), zi.SHORT, Locale.US)); // zzz } else { sb.append("GMT"); } So if zi is empty it will append GMT. So in the machine you specifying check what is returned by date.getZone. – Aajan Mar 01 '16 at 09:25
  • 1
    By the way, other libraries like Joda-Time etc. would suffer from the same problem to determine the system timezone, see my answer. This even includes Java-8. It is also questionable to recommend a project whose project owner himself officially recommends to go away from it (to Java-8). – Meno Hochschild Mar 01 '16 at 15:37
  • I have seen your answer. I was not aware of that. Thank you. – Aajan Mar 01 '16 at 15:43
1

A java.util.Date object represents a timestamp. A timestamp is a specific moment in time and has no concept of a timezone. When displaying a java.util.Date you need to format the time with respect to a given timezone.

The usual way to do this is using java.text.DateFormat:

Date d = new Date()
DateFormat dateForamt = DateFormat.getDateTimeInstance()
// The default timezone is the timezone that is default for the user, but it
// can be changed like so:
dateFormat.setTimeZone(someTimezone)
System.out.println(dateFormat.format(d))
Elias Mårtenson
  • 3,820
  • 23
  • 32
  • But as per the link I have shared from stackoverflow it should always be according to systems timezone by default So my question is why is it showing abnormal behavior!!!!! – Nikhil Agrawal Mar 01 '16 at 09:03
  • 1
    That is not actually the case. In early versions of Java, the `java.util.Date` class was responsible for handling a lot of things that are done by DateFormat and Calendar today. When this changed, the definition of Date changed to become a simple timestamp object. However, the code to handle timezones is still in there, but are deprecated. That means that you can in fact set the timezone of a Date object, in which case that timezone will be used in the `toString()` method. – Elias Mårtenson Mar 01 '16 at 09:50