GWT Date and Time serialization

3,825 views
Skip to first unread message

sim123

unread,
Oct 16, 2008, 2:21:01 PM10/16/08
to Google Web Toolkit
Hello,

I noticed strange behavior of GWT serialization when handling Date/
Time/Timestamp values. When client and servers are in different time
zones like server is in GMT and client is running in PST time zone,
RPC does timezone conversion for Date/Time and Timestamp, I am not
sure if this is acceptable behavior and if it is then is there a way I
could disable this conversion. Here is the example
public class DateTest implements EntryPoint {

public void onModuleLoad() {


Button b = new Button();

b.addClickListener(new ClickListener() {

public void onClick(Widget sender) {
DateServiceAsync dateService = DateService.Util.getInstance();
dateService.getTimestamp(new AsyncCallback<Timestamp>(){

public void onFailure(Throwable caught) {
// TODO Auto-generated method stub

}

public void onSuccess(Timestamp result) {
TextBox tBox = new TextBox();
tBox.setText(result.toString());
RootPanel.get().add(tBox);
}

});
}

});
RootPanel.get().add(b);
}

Service Implementation

public class DateServiceImpl extends RemoteServiceServlet implements
DateService {

public Timestamp getTimestamp() {
Timestamp t = new Timestamp(System.currentTimeMillis());
System.out.println("timestamp at server" + t);
return t;
}

If server is running on GMT Time and client browser is in different
timezone GWT does conversion (even for Date and Time types).
Please suggest. Thansk for all the help and support.

sim123

unread,
Oct 16, 2008, 4:28:36 PM10/16/08
to Google Web Toolkit
I looked into serialization code for Date/Time and Timestamp in
com.google.gwt.user.client.rpc.core.java.sql package, it seems that
these classes are cause of time zone conversion, is that so and is it
expected behavior?? Some one please help me.

Thanks.

sim123

unread,
Oct 16, 2008, 5:57:49 PM10/16/08
to Google Web Toolkit
Can some one please reply to my post, please!!!
I just want to know if it is expected behavior, and if it is can I
create custom serializer for not doing this conversion for example I
tried changing Date_CustomFieldSerializer .java's code in to GWT
source to be

public static void deserialize(SerializationStreamReader
streamReader,
Date instance) {
// No fields
}

public static Date instantiate(SerializationStreamReader
streamReader)
throws SerializationException {
Date d = Date.valueOf(streamReader.readString());
return d;
}

public static void serialize(SerializationStreamWriter streamWriter,
Date instance) throws SerializationException {
streamWriter.writeString(instance.toString());
}

and it worked, it is not doing any conversion for Date, however I
don't want to play with real GWT's code so just wondering if I could
write custom serializer for java fields?

I would really appreciate any help. Thanks

Tahir Akhtar

unread,
Oct 17, 2008, 12:36:01 PM10/17/08
to Google Web Toolkit
There is another issue related to serialization of dates that can
occur due to emulation of long with double in generated JavaScript.

See:

http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/1108020196cbf3f6

Manuel Carrasco

unread,
Oct 17, 2008, 12:46:23 PM10/17/08
to Google-We...@googlegroups.com
I had the same problem passing java.util.Date from client to server. When they use different TZ,  dates differ. Eventually I use String representation of the dates for client/server dialog, and use DateTimeFormat for transformations.

sim123

unread,
Oct 17, 2008, 2:56:22 PM10/17/08
to Google Web Toolkit
Oh!! so no one knows is it the expected behavior? Or it could be
changed? Can any one please suggest that creating custom serializers
for java classes is a good idea or not and what could be the pros and
cons of this approach?

Thanks.

On Oct 18, 5:46 am, "Manuel Carrasco" <manuel.carrasc...@gmail.com>
wrote:
> I had the same problem passing java.util.Date from client to server. When
> they use different TZ,  dates differ. Eventually I use String representation
> of the dates for client/server dialog, and use DateTimeFormat for
> transformations.
>
> On Fri, Oct 17, 2008 at 6:36 PM, Tahir Akhtar <tahir.akh...@gmail.com>wrote:
>
>
>
> > There is another issue related to serialization of dates that can
> > occur due to emulation of long with double in generated JavaScript.
>
> > See:
>
> >http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa...

Jason Essington

unread,
Oct 17, 2008, 4:08:25 PM10/17/08
to Google-We...@googlegroups.com
Of course this is expected behavior! When you are talking about time,
that time is relative to your location. Just because it is noon where
you are, doesn't mean it is noon where I am.

If you are in New York, and post a schedule to your server that
indicates that you will be having a conference call at 4pm, when your
associate in LA pulls up the schedule, you don't want it to say 4pm,
you want it to say Noon, otherwise you'll miss each other by 4 hours.
And what about your partners in India? you don't want them to have to
guess at what time zone you set that schedule in, then try to figure
the offset on their own.

If you don't want to take into account timezones when passing date/
time back and forth between the server, simply serialize the data
yourself to something that doesn't include time zones ... like a
string "Jan 28, 2008 1:45pm"

-jason

sim123

unread,
Oct 17, 2008, 5:44:06 PM10/17/08
to Google Web Toolkit
Thanks for response Jason but what about dates, I am setting my
birhtday as today's date and somebody who is in different timezone,
GWT does conversion of birthdate (one day ahead or one day late), for
example if you set any date to be 10-15-2008 you will see same date as
either 10-14-2008 or 10-13-2008 respective to the server's time zone,
is it expected!!

Another case is I sent an invite saying come to my home this monday at
4:00 pm, if you are in different time zone you will see same thing as
come to my home on this Monday at 7:00 pm (as GWT did Time
conversion), is it expected too!!

I think this is the data which is being converted and any program
should not play with user's data, GWT is doing this conversion then to
without any documentation, even if it is expected behavior, it should
be documented and there should be some way to disable this auto
conversion. I don't think passing Strings back and forth would be a
good idea, if I have Date object inside a map/list i need to traverse
through that list/map convert this date into String and return it to
client where client does same thing again, I can not construct a
String right from the beginning as database is returning me Date and
there could be so many different problems with different approaches, I
would prefer to write my own custom serializers in this case, can you
or anyone please tell me what is the problem with the serializer I
mentioned in my previous post?

Thanks

kozura

unread,
Oct 17, 2008, 6:57:50 PM10/17/08
to Google Web Toolkit
But Jason is exactly right, to be precise in a time-zone-spanning app,
you have to say come to my home at 4pm PST. GWT isn't doing anything
magic or secret here in conversion, a Date is really a 64 bit number
representing the milliseconds since 1970, in GMT. Your local machine
then converts supplies the proper locale offset to the Date class,
which gives you the local time corresponding to that number. The
number itself is never changed.

Perhaps a better solution that would better represent what you seem to
want, would be to keep the intended time zone offset along with the
actual date - maybe extend Date to do this. So Joe in Oregon says
meet me on Monday at 4pm, use date.getTimezoneOffset() to see what
time zone this appointment is intended to be in. Store it in the
database and everything. When Jane in NYC retrieves it, you can show
it in her time (7pm), or in "Oregon local" time by simply adding the
difference in offsets. This gives you the benefit of storing the date
in a Timezone neutral fashion as is natural and correct to do, but
still be able to display it as the time in the original locale.

jk

Chris

unread,
Oct 17, 2008, 11:49:54 PM10/17/08
to Google Web Toolkit
As others replied, this is the expected behavior. However, I also had
the need to make sure the date object was not changed due to different
timezones of the client and server. There is another thread, I don't
have a link to it handy but you could search for something like "date
serialization", where it was suggested to replace the gwt default date
serialization logic. That is what I did.

Warning, you need to compile the GWT java libraries yourself and this
change affects all Date serialization. Since that is what I wanted, I
didn't look for a more refined method that I could be applies to only
specific dates. Here is what I replaced:

The following file is in the user/src directory of the gwt source
tree.

Good luck,
Chris....
================================================================
package com.google.gwt.user.client.rpc.core.java.util;

import com.google.gwt.user.client.rpc.SerializationException;
import com.google.gwt.user.client.rpc.SerializationStreamReader;
import com.google.gwt.user.client.rpc.SerializationStreamWriter;

import java.util.Date;

/**
* Custom field serializer for {@link java.util.Date}.
*/
public final class Date_CustomFieldSerializer {

public static void deserialize(SerializationStreamReader
streamReader,
Date instance) {
// No fields
}

public static Date instantiate(SerializationStreamReader
streamReader)
throws SerializationException {
// return new Date(streamReader.readLong());
return new
Date(streamReader.readInt(),streamReader.readInt(),streamReader.readInt(),streamReader.readInt(),streamReader.readInt());
}

public static void serialize(SerializationStreamWriter streamWriter,
Date instance) throws SerializationException {
// streamWriter.writeLong(instance.getTime());
streamWriter.writeInt(instance.getYear());
streamWriter.writeInt(instance.getMonth());
streamWriter.writeInt(instance.getDate());
streamWriter.writeInt(instance.getHours());
streamWriter.writeInt(instance.getMinutes());
}
}

Jason Essington

unread,
Oct 20, 2008, 3:33:45 PM10/20/08
to Google-We...@googlegroups.com
The issue here is that you don't seem to like the established behavior
of dates.

This is not a GWT issue, but rather the well known behavior of dates
in general.

If you don't want date behavior, then use a format that doesn't
exhibit this behavior (Strings tend to work nicely).

-jason

sim123

unread,
Oct 20, 2008, 6:55:53 PM10/20/08
to Google Web Toolkit
Thank you so much Chris, this worked.
Reply all
Reply to author
Forward
0 new messages