9

GWT doesn't serialize Java Date properly. When I tried sending Date created in Javascript through the wire, I found out that dates between April 1st (funny) and 25th October for years before year 1983 get subtracted by one day.

That means that, say, both 1982-04-01 and 1982-03-31 become 1982-03-31 on the Java side.

Given the dates in question, I would guess that this is some kind of DST problem. I've tried googling, and found only one other reference that describes similar problem.

I also tried submitting bug to the GWT team, but curiously wasn't able to find bugtracker for GWT.

So, my questions are:

  1. Anyone else run into this? I'm on GWT 1.7, and would like to confirm if this happens on 2.0 as well.

  2. My workaround was to send dates as Strings, and parse them on server. Anyone knows better workaround?

Domchi
  • 10,705
  • 6
  • 54
  • 64
  • 1
    We have run into other Date related problems (don't know anymore what they were) so we switched to Strings. – Drejc Jan 20 '10 at 20:40

6 Answers6

5

Assuming that you are using a java.util.Date

Question 1: It seems that it is fixed in 2.0. I've created both Dates above (1982-04-01 and 1982-03-31) and they come through correctly to the server (both represent on the server as 1982-04-01 and 1982-03-31 respectively). My setup is:

  • GWT 2.0
  • Java 1.6
  • OSX 10.6.2

Question 2: You could always pass the 'milliseconds since January 1, 1970, 00:00:00 GMT' over the async service-which you can get using getTime() on the date object. On the server side you can then instantiate a new Date passing this value in on the constructor:
Date date = new Date(millis);
This saves fiddling around with formatters and parsers.

Raymond Barlow
  • 489
  • 1
  • 3
  • 9
  • 1
    Actually GWT is already serializing using milliseconds, but it drops the timezone. So a "3. April 2001 00:00 GMT" in the browser may become "2. April 2001 23:00 CET" on the server. And if you only look at the date it seems to be a day off, even though the actual time means the same. – Stroboskop Jan 20 '12 at 13:31
2

Dates and times are a complicated subject. The conversion can depend on the locale that the browser is running in and wether both you JVM on the server and the locales of the clients are up-to-date.

In some cases there can be differences because in some regions they switched timezones in the past.

GWT sends dates using just millis since epoch time. Since it is using Date objects, you are limited in that the Dates on the server side will be automatically modified to the servers timezone. Are you sure that you take into account the possible difference in timezones between client and server ?

David

David Nouls
  • 1,895
  • 12
  • 21
  • In my case, server and client were both running on the same machine, so it's definitely GWT serialization problem. – Domchi Jan 23 '10 at 03:54
  • They maybe in the same timezone NOW. But looking at the dates, i think you just discovered daylight savings time. And one of the machines/services doesn't take that into account when serializing the time. And regardless of that - i don't think you want to do a webservice that depends on the browser's timezone being the same as the server's. – Stroboskop Jan 20 '12 at 13:25
2

I'm pretty certain the FTR library has some date emulation in it.

http://code.google.com/p/ftr-gwt-library

Stuart Ervine
  • 1,024
  • 13
  • 15
1

If you don't have to do client-side conversions (adapt to user's timezone) or calculations send it in a String from the server.

Never came across your specific problem though.

Iker Jimenez
  • 7,105
  • 9
  • 49
  • 46
1

The possible problems soure is difference in Client/Server time zones.

hsmishka
  • 91
  • 6
  • See my response to David, client and server are in the same timezone. I believe that the problem is that Javascript and Java handle dates differently, so sending milliseconds is not good enough. – Domchi Jan 12 '11 at 09:34
0

We have also run into a similar problem. It was long enough ago that I do not remember the exact details but the gist of it was there were some minor differences between java.util.Date and the way dates were handled in Javascript. Our workaround was effectively the same as yours, where the actual value sent over the wire was generally a String.

bikesandcode
  • 1,033
  • 9
  • 16