Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is there other solution than hack Date_CustomFieldSerializer and recompile GWT

I've been searching for a while about java.util.Date Serialization and the different client / server locales issue.

For those of you that are not informed about the matter, here is a short explanation:

GWT Date Serialization in RPC are done in function of the locales that you have. So if client an server have different locales, the user could input one date and the server will end up storing other date on the database, depending on its locale.

This is a expected behavior and in many cases seems to be the correct one.

For example if you schedule meeting for some date / hour from a browser in NY, is correct that the guy checking the meeting time in SF see a corresponding locale value.

Now what about Date of Birth? In this case, if you Born on the 5 of December, it doesn't looks accurate that some guy in china read that you born on the 6 of December.

Some guys tell that one solution could be using Strings instead of Dates, but I don't think so, basically because for instance you couldn't add or substract Strings.

So the best way of solving this I think is a Custom Serialization, but unfortunately GWT is providing its own Date_CustomFieldSerializer.

And for what I read, the only solution to this is do your own version of this file and recompile GWT sources. I don't want to do that, so that is why I'm asking if anyone knows any better solution, or if GWT guys are planning for example some plugin serialization infrastructure for future releases.

Thanks in advance. Daniel

like image 305
Daniel Ardison Avatar asked May 29 '12 13:05

Daniel Ardison


1 Answers

A java.util.Date represents some specific instant in time. You're born at a specific instant in time; it might have been December 5th in your timezone but December 6th in Chine, that doesn't change the exact instant when you're born.

It seems like you want to store a "day-month-year" triplet rather than a specific instant in time. If that's the case, then store it as triplet (possibly serialized as String), not a java.util.Date; in other words, use the right tool for the job.

You say that you think it'd be wrong, because “you couldn't add or substract Strings”. Well, you don't add or substract dates either. If you want to do some calculations with dates, then either it means you actually want to store a date (and live with the fact the Chinese guy see you're born on December 6th, because that's the date you happen to be born at in his timezone, rather than December 5th, which was the date in your timezone), or you want to temporarily transform your DMY triplet to a date (and making approximate calculations, leading to your Chinese friend wishing you your birthday one day too early: December 5th in his timezone when it's still December 4th in your timezone).
It's rather easy, using DateTimeFormat, serializing/parsing a date to DMY (yyyy-MM-dd for instance) and always using the current timezone.

BTW: saying GWT Date Serialization in RPC are done in function of the locales that you have is not accurate: GWT serializes the date's timestamp (seconds since Epoch, as returned by java.util.Date#getTime()), which is specifically not timezone-dependent.
Not to mention that locale != timezone.

like image 197
Thomas Broyer Avatar answered Sep 21 '22 16:09

Thomas Broyer