Is there any other solution than hacking Date_CustomFieldSerializer and recompiling GWT

Question

I searched for some time about java.util.Date Serialization and problems with different local clients / servers.

For those of you who are not informed about this, here is a brief explanation:

GWT Session Date Serialization in RPC is performed depending on the locales that you have. Therefore, if the client has different locales, the user can enter one date, and the server will eventually save another date in the database, depending on its locale.

This is the expected behavior and in many cases seems correct.

For example, if you are planning a meeting for a certain date / hour from a browser in New York, it is correct that the guy checking the time of the meeting in SF sees the corresponding value of the language standard.

How about a date of birth? In this case, if you were born on December 5, it does not seem that some guy in China read that you were born on December 6.

Some guys say that one solution can use strings instead of dates, but I don’t think so, mainly because, for example, you could not add or subtract strings.

So, the best way to solve this, I think, is custom serialization, but unfortunately GWT provides its own Date_CustomFieldSerializer .

And for what I read, the only solution for this is your own version of this file and recompilation of GWT sources. I don’t want to do this, so I ask if anyone knows a better solution, or if the GWT guys are planning, for example, some plugin serialization infrastructure for future releases.

Thanks in advance. Daniel

Answer 1

A java.util.Date represents a particular point in time. You are born at a certain point in time; it could be December 5th in your time zone, but December 6th in China, this does not change the exact moment when you are born.

It seems that you want to store the day-month-year triplet, not a specific point in time. If this is the case, then save it as a triplet (possibly serialized as String), not java.util.Date ; in other words, use the right tool for the job.

You say you think it was wrong because "you could not add or subtract lines." Well, you do not add or write out dates. If you want to make some calculations with dates, then either that means you really want to keep the date (and live with the fact that the Chinese guy sees that you were born on December 6, because on the day you were born in his time belt, not December 5th, which was the date in your time zone), or you want to temporarily transform the DMY trimlet into a date (and make rough calculations, which will cause your Chinese friend to wish you your birthday one day too early: December 5 in his time zone, to GDS he is December 4 in your time zone).
It's quite simple using DateTimeFormat , serializing / parsing dates on DMY ( yyyy-MM-dd for example) and always using the current time zone.

BTW: they say that the serialization of GWT Date in RPC is carried out depending on the locales you have, are inaccurate: GWT serializes the date stamp (seconds since Epoch, as java.util.Date#getTime() was returned), which is not specifically time dependent.
Not to mention that locale! = Timezone.