You just need to remember that a Date object (always) stores date/time as milliseconds since epoch in the UTC/GMT time zone. What trips people up is that the Date.toString() method returns a text representation in the JVM's default time zone (via an internal Calendar object). (Take a look at JDK source code.)
So for instance on my machine
Date now = new Date();
System.out.println(now.toString());
System.out.println(now.getTime())
will give
Fri Oct 02 06:56:24 EST 2009
1254430584531
The milliseconds number being the actual milliseconds since epoch in the GMT/UTC time zone.
You should always use Date formatters or Calendar instances when manipulating/using Date objects. For example:
Date now = new Date();
SimpleDateFormat sdf = new SimpleDateFormat("EEE MMM dd HH:MM:ss zzz yyyy");
sdf.setTimeZone(TimeZone.getTimeZone("UTC"));
System.out.println(now.toString());
System.out.println(sdf.format(now));
gives
Fri Oct 02 06:56:24 EST 2009
Thu Oct 01 20:56:24 UTC 2009
In summary: Always treat a Date object as data only, milliseconds since epoch. (Don't use any of the Deprecated methods, and don't use toString() unless you understand what it is displaying.) To display, format, convert (add subtract time etc) date/time always use a Calendar instance or DateFormat implementation and it is hard to go wrong.
As the Javadoc says for Date:
'Prior to JDK 1.1, the class Date had two additional functions. It allowed the interpretation of dates as year, month, day, hour, minute, and second values. It also allowed the formatting and parsing of date strings. Unfortunately, the API for these functions was not amenable to internationalization. As of JDK 1.1, the Calendar class should be used to convert between dates and time fields and the DateFormat class should be used to format and parse date strings. The corresponding methods in Date are deprecated.'
Experiment for yourself with Date's, Calendars and Formatters and read the Javadoc and it will become a little clearer.
For the first part of your question you shouldn't need to set the time zone of your Glassfish server to accommodate your data. If you want to store time zone data with your data/time values then use Calendar rather than Date in your objects. Or as I usually do, everything is stored as UTC time (in db and Date instances in objects) and time zones are only used when data is displayed/outputted or parsed. So when your data is received parse it with a DateFormat or equivalent with time zone set to +01:00 (it may pick that up from the time string automatically if it has the time zone attached as you example shows).
I don't know specifically about the second part of your question but if the implementation of your web-service end handles Dates correctly and parses them correctly it should handle this without your intervention.
