PDA

View Full Version : GXT Showing diffent date in different locations



sathishb
21 Dec 2010, 3:04 PM
Users are accessing the server located in London from various geographic locations. Users see different dates when they access. I tried to connect to the London server's DB locally using the workspace and recreate the problem, unfortunately I do not see the problem happening. I have tried to set the GWT locale option like below :-
I have set the following property to set the locale value to "uk" in the gwt module xml file. (

<inherits name="com.google.gwt.i18n.I18N"/>
<extend-property name="locale" values="uk"/>).
The above setting did not solve the problem. I have also tried I18N - DateTimeFormat to format the date before rendering, that did not work too.
Have anyone seen this problem? How did you solve it? It's GXT (or) GWT (or) my Gwt settings problem?

Your help is highly appreciated.

Regards,
Sathish.

sven
21 Dec 2010, 5:27 PM
GWT is doing all this, we are not doing anything of it that would format date, changes the timezone. We just use what GWT offers.

sathishb
21 Dec 2010, 6:26 PM
Hi sven - I agree with you. Can you just verify the settings I have mentioned in the module xml is right? Just to make sure that locale datatime is set to UK? (or) are you aware of any specific setting other than locale required for datetime?


<inherits name="com.google.gwt.i18n.I18N"/>
<extend-property name="locale" values="UK"/>

If the above setting is correct then what could be the possible fix to avoid the different date showing in different geographic locations?

I appreciate your hep!

sathishb
23 Dec 2010, 11:11 AM
To people who is reading this thread. Here is the solution --

The problem was java.util.Date. Here is the API description à

“The class Date represents a specific instant in time, with millisecond precision.
Prior to JDK 1.1, the class Date had two additional functions. It allowed the interpretation of dates as year, month, day, hour, minute, and second values. It also allowed the formatting and parsing of date strings. Unfortunately, the API for these functions was not amenable to internationalization. As of JDK 1.1, the Calendar class should be used to convert between dates and time fields and the DateFormat class should be used to format and parse date strings. The corresponding methods in Date are deprecated.
Although the Date class is intended to reflect coordinated universal time (UTC), it may not do so exactly, depending on the host environment of the Java Virtual Machine. Nearly all modern operating systems assume that 1 day = 24 × 60 × 60 = 86400 seconds in all cases. In UTC, however, about once every year or two there is an extra second, called a "leap second." The leap second is always added as the last second of the day, and always on December 31 or June 30. For example, the last minute of the year 1995 was 61 seconds long, thanks to an added leap second. Most computer clocks are not accurate enough to be able to reflect the leap-second distinction.
Some computer standards are defined in terms of Greenwich mean time (GMT), which is equivalent to universal time (UT). GMT is the "civil" name for the standard; UT is the "scientific" name for the same standard. The distinction between UTC and UT is that UTC is based on an atomic clock and UT is based on astronomical observations, which for all practical purposes is an invisibly fine hair to split. Because the earth's rotation is not uniform (it slows down and speeds up in complicated ways), UT does not always flow uniformly. Leap seconds are introduced as needed into UTC so as to keep UTC within 0.9 seconds of UT1, which is a version of UT with certain corrections applied. There are other time and date systems as well; for example, the time scale used by the satellite-based global positioning system (GPS) is synchronized to UTC but is not adjusted for leap seconds. An interesting source of further information is the U.S. Naval Observatory, particularly the Directorate of Time at: “
The outcome is the java.Util.Date – “is intended to reflect coordinated universal time (UTC), it may not do so exactly, depending on the host environment of the Java Virtual Machine” .

So, we should use Calendar/DateFormat (or) convert the java.sql.Date (from resultset) to java.util.Date then use date formatter & set the formatted value to the String and send that String value over to the UI client side renderer (GWT/GXT/DOJO).

Bottom line is java.util.Date will behave differently based on the host environment/JVM.