Thanks G.edwin,
I got it working this way, the problem I still had was in web mode in combination with tomcat. Since it is not easy to control the Classloader in tomcat the gwt-servlet.jar was always loaded prior to my jar named owhatever.jar. I figured out that tomcats classloader order is alway alphabetic so that g*.jar is always loaded prior to o*.jar. So the com.google.gwt.user.client.rpc.core.java.util.Date_CustomFieldSerializer class was always token from gwt-servlet.jar. To Solve this one could either rename the jars to be loaded in the desired order which I did not like since this might be implementation dependent or to include the code from gwt-servlet.jar except of the Date_CustomFieldSerializer class within my owhatever.jar which I finally did!

I would suggest you educate your users, rather than change anything.
If someone modified a record at 1000 in Paris, it was 0900 in London.
Since the user in Paris sees 1000 and the one in London see 0900, both representing the same instance in local time, I fail to see the problem.
By the way, if a user in London saves 1000 and then sees 0900, there is a problem in the way you are saving dates, always marshall dates as Date, not String.
If a user in London saves 1000 and then sees 1100, there is a problem in the way you are reading dates, always read Date and transfer Date, not formatted dates as String from the DB server.
I went through the same nightmare with users in a dozen timezones, as long as you only transfer Date back and forth, the problem is gone.

I put my own Data serializer inside the same package on my project but something rare is happening.

When a Date is going to serialize the GWT Date serializer is used, but when the Date is going to deserialize my own Date serializer is used ¿?¿?¿?, I don't know what is the problem. Anyone can help me please?