GWT Date Serialization problem

[SVR]

Has anybody noticed a problem with dates and RPC. Basically I receive a date from the backend and able to see the correct date in the RPC Impl in the debugger but when I set the Date field on the client (after the the results are serialized), I see that the date is offset by a day.
I havnt tested extensively for what dates cause this problem, but I do see this randomly. Yes the Client and the Server are in different time zones, but I am not setting the time component (using sql.date on the server side, which essentially has no time component).

Anybody has encountered this before? I can work aound this (by passing the DD, MM, YYYY components separately), but want to understand the problem better.
Thanks

[Juan Pablo Gardella]

How are you do "when I set the Date field on the client"?

The serialization to server->client is Ok, but to client->server fail?

Juan

2011/3/31 SVR <svr...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[SVR]

Serialization from Client to Server is OK, but Server to Client fails.
I enter say Jan 31, 1979 (a simple Text with DatePicker) and it get saved to the Database as such, but when I get back the value from the server, I can see the correct value in the server (RPC Impl) as Jan 31, 1979, but when it comes back to the client after the RPC call, the value is Jan 30, 1979.

[Juan Pablo Gardella]

You sent the date to client via a asynchCall. So you receive onSuccesfull or onFailure. You are update in onSuccesful the date of the simple text with which value? Can you share the relevant code?

Are you use DateBox?

Juan

2011/3/31 SVR <svr...@gmail.com>

[SVR]

Simplifying my use case:

I have a Text box from which I read the value from:

Sender is a shared datastore between the client and the server and is of the form:
Sender{
   java.util.date dateOfBirth;
     }

GWT Client Side:

    TextBox birthDate;
    String medDateFormat = locale.getDateTimeFormatInfo().dateFormatMedium();
    String dateString = birthDate.getText();
    Date  date = DateTimeFormat.getFormat(medDateFormat).parse(dateString);
    sender.setDateOfBirth(date);


This date is being passed to an RPC and stored in the DB.

RPC save:
        java.sql.Date birthDate = null;
        if (sender.getDateOfBirth() != null) {
            SimpleDateFormat sqlformat = new SimpleDateFormat( "yyyy-MM-dd" );
            birthDate = java.sql.Date.valueOf(sqlformat.format(sender.getDateOfBirth()));
        }
and birthDate is stored in the DB.

So far its fine.

When I read back the data:
RPC read method:
java.sql.date date1
 sender.setDateOfBirth(date1.getTime());

GWT Client:
        if (sender.getDateOfBirth() != null)
            this.birthDate.setText(DateTimeFormat.getFormat(medDateFormat).format(
                sender.getDateOfBirth()));
        else
            birthDate.setText("");


Now I see the value on the textBox has changed, is off by a day!

[Josh Berry]

Pretty sure this is a simple issue of the timezone messing things up.
(Sorry for not having a solution right off, just something to look
into.)

[Juan Pablo Gardella]

Check if the value returned by "public long Date.getTime()" are different. 

In dabase is store correctly suppose.

2011/3/31 Josh Berry <tae...@gmail.com>

[cri]

I've experienced and have had to deal with this problem. It is a
timezone related problem. Here's an example.

1) You initialize a Date object from the database on the server side.
Say the date in the database is March 15. Your Date object will be
initialized to March 15 at midnight, because a Date object encodes an
instant in time, not just a calendar day.

2) Now you pass the Date object to the client layer in a later
timezone, say from Eastern to Central timezones. In the central
timezone March 15 at midnight translates to March 14 at 11pm. So, the
calendar day is off by one.

You get a similar problem when passing dates from the client to the
server.

The solution that I've always used is to pass dates between the GWT
client and server as Strings, e.g. MM/dd/yyyy.

On Mar 31, 3:10 pm, Juan Pablo Gardella <gardellajuanpa...@gmail.com>
wrote:

[Martin Larsson]

On 31. mars 2011 22:33, cri wrote:
> The solution that I've always used is to pass dates between the GWT
> client and server as Strings, e.g. MM/dd/yyyy.

Or set the time component to noon instead of midnight.

M.

[Brendan Doherty]

How will noon fix the problem?

Assuming your server is running on central time (UTC-6) and you pass it to a client I'm running here in New Zealand (currently UTC+13), your March 15 noon will become March 16 6am.  You'll still be a day off.

[Juan Pablo Gardella]

But is the same time. I think gwt serialize the long value of the time and then create a date in client side with this value. Is this correct?

2011/4/1 Brendan Doherty <bre...@propertysimplified.com>

How will noon fix the problem?

Assuming your server is running on central time (UTC-6) and you pass it to a client I'm running here in New Zealand (currently UTC+13), your March 15 noon will become March 16 6am.  You'll still be a day off.

--

[Paul Robinson]

The standard GWT RPC serialization for dates writes out the long value, so that should be sent correctly. The error comes because when you convert that long to a string, you do so in a particular timezone, and your choice of timezone can change the day that you think this time point occurred on.

Passing your dates as strings, or some other custom encoding will fix the problem. The other option is to change GWT by writing your own custom field serializers for java.util.Date, java.sql.Date and java.sql.Timestamp so that it sends dates with separate values for day, month and year.

See http://groups.google.com/group/google-web-toolkit/browse_thread/thread/5c397f3ffc4e24fa/a925fc77879fa6b6

Paul

[Andy]

This is the reason we created the UTCDateBox. We only send a Long back
and forth between the client and server and that Long always
represents midnight in UTC. This avoids confusion when users in
different time zones are choosing dates.

You can see the UTCDateBox demo and source:

http://code.google.com/p/gwt-traction/

Cheers,
Andy